yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] Stevethegreat:
Yeah I saw that and it's probably sth I can try but if I do, a) there's a good chance that I may not find a lightweight enough launcher because my screen's resolution will still blow its ram usage and b) supercharger would ask me to bulletproof my launcher everytime I run it and would always try to install the jar files... which is rather tiring.

I thought having supercharger killing my launcher would had been a more elegant solution but from your words' context I understand that that's rather hard to do, no?
[Android Software/Hacking General [Developers Only]] Tomislav Veličanstveni:
what does that mean?
[Android Software/Hacking General [Developers Only]] da__beast:
Supercharger doesn't kill anything - it makes your system more efficient at memory management and the system will kill as needed.

Look at what Zep told you to do. That is how you will get it done with the Supercharger. If you don't want to do it that way - uninstall and find another way.

---------- Post added at 06:12 PM ---------- Previous post was at 06:10 PM ----------

What part don't you understand?
[Android Software/Hacking General [Developers Only]] zeppelinrox:
How often do you run it? :P

If you goto options, select 0 for scrolling speed even if 0 isn't displayed so at least it goes by fast for next time.

If you wanted to patch services.jar with different priority, grab the zip version and edit Ultimate Jar Power Tools script.

Find:

homenew=0x$launcheradj

Change to:

homenew=0xf

That would make it a 15 ADJ priority.

Oh wait... I forgot that I made it log automatically... LOL

Find and attach /data/Log_KickAssKernel.log
[Android Software/Hacking General [Developers Only]] Stevethegreat:
Oh but it does kill apps, not directly but certainly indirectly.... if -say- put a low priority to a process it would be the first to be killed, no? That's what I wanted to do to my launcher..

@zeeppelinrox : thanks for the tip. Didn't know you can put "0" to message speed would certainly try it. As for the priorities stuff that's Exactly what I was looking for (but didnt know kow to expesss it) thanks ;)
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Ok cool.

Feel free to click thanks on all my posts lol
[Android Software/Hacking General [Developers Only]] da__beast:
Using that logic so does a memory hungry game that launches. Indirectly it kills apps because it needed more memory to run so your android device killed apps to make room.

Supercharger makes your system more efficient - if you had 1TB of RAM you probably wouldn't have any apps get killed. If you only have 256MB you have a lot get killed. Supercharger didn't change that - people are going to read these posts and think they can selectively kill apps with Supercharger.
[Android Software/Hacking General [Developers Only]] Tomislav Veličanstveni:
There isn't that file. I made a backup before running KAK so when my phone bootloop I restored system, so there is just a Log_Supercharger.log
[Android Software/Hacking General [Developers Only]] UpInTheAir:
Smack away :)

---------- Post added at 03:44 PM ---------- Previous post was at 03:38 PM ----------

BTW zep,

Including again your tweaks into my next SkyHigh GT-P6810 ROM release as optional (but highly recommended) Aroma options :cool:

v10 teaser is running well and services.jar patched die hard with RC6 and all tweaks etc and scripts running on init.d boot. Also the entropy fix....

Love it :thumbup:
[Android Software/Hacking General [Developers Only]] warhead1978:
Hmmm , try to explain it short LMK

3 or 4 Levels of Apps

The background, system needed one, never killed

The foreground, multitasking in Memory , several services like keyboard whatsup etc. which can be killed when Memory is needed...

The visible ... the one is active

the launcher will get the First level with super charged and services get priority Levels

Memory will ever reserved for the visible one and the third set value in freemines (?)

Launcher will stay so long as possible in Memory with visible App as priority Level one ....

correct?

MfG
[Android Software/Hacking General [Developers Only]] zeppelinrox:
when supercharged, server apps are in slot 3.

launcher and visible apps are in slot 2.

They're able to be in the same slot because of the OOM grouping fix which makes more room in slot 2.

Just look at the boomstick.
[Android Software/Hacking General [Developers Only]] mixednuts:
Actually, if you were using the teaser V6, you would see that zep already modified the script to note "0" as a scrolling speed option. :cool:
[Android Software/Hacking General [Developers Only]] GermainZ:
That was also in the older versions. You can pretty much put any integer anyway...
[Android Software/Hacking General [Developers Only]] mixednuts:
oh, I don't remember the past script spitting out "0" as an option... ok, thanks. If it was there I'm not suprised... I swear that my memory's been rewired for the worst. :silly:
[Android Software/Hacking General [Developers Only]] zeppelinrox:
You only see the 0 option if you're 100% SuperCharged ;)

but it won't accept anything higher than 3 lol
[Android Software/Hacking General [Developers Only]] mixednuts:
Curious, zep, what d'you think about the following recent posts (in another thread)?

??
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Yep I'm inclined to agree since the setting doesn't effect write speed - just read speed.

In SuperCharger I have it dependent on how much ram.

if [ "$ram" -lt 512 ]; then sdtweak=1024
else sdtweak=2048
fi

On low ram devices there is a memory hit in that a chunk is wasted which is why I made it dependent on ram.

Initially I had only half those values... 512 kb for lower ram devices and 1024 kb for higher ram devices.

Hmm... I thought I had mentioned something about it in the script but turns out it's not... it's in the changelog from when I first added it:

I ended up increasing it mainly due to user requests and because device RAM doesn't really come into play on newer devices.

Lots were and still are using 3MB or 4MB caches but that was never a consideration since I never noticed a difference.

If you've tested with an app like sd tools, do you see a difference between setting it to 512 or 1024?

Edit: Also, I don't think it effects ext partitions on the sdcard... only fat32... I may be remembering incorrectly but I'm pretty sure that's right.

And hey... how's "-=Engine Flush-O-Matic=-" sound? lol
[Android Software/Hacking General [Developers Only]] mixednuts:
This is interesting, if using app2sd type tools /scripts it's almost as if one would experience less lag while setting read-ahead to it's absolute lowest level... less processing lol (unless, of course, transferring files to / fro your PC in mass storage mode)

Given that dk_cool-zero thinks it's relevant for his script I would think the read-ahead does affect ext, no?

Wicked... reminds me of Maniac Mansion for some reason!? :eek:
[Android Software/Hacking General [Developers Only]] GermainZ:
_
| |
___| |
( .'
) ( -zoom-

_
| | -=Engine Flush-O-Matic=-
___| |
( .'
) ( -zoom-

_
| | -=Engine Flush-O-Matic=-
___| |
( .'
) (

_
| | -=Engine Flush-O-Matic=-
___| |
( .' by
) (

_
| | -=Engine Flush-O-Matic=-
___| |
( .' by
) ( -zoom-

_
| | -=Engine Flush-O-Matic=-
___| |
( .' by
) ( -zoom- -zoom-

_
| | -=Engine Flush-O-Matic=-
___| |
( .' by zeppelinrox
) ( -zoom- -zoom-

ascii art from http://www.ascii-art.de/ascii/t/toilets.txt
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Ah ok I mis-remembered :)

I think that's as good an explanation that you can get :cool:

Wowz... flush that cack cache! lol
[Android Software/Hacking General [Developers Only]] zeppelinrox:
ugh... maybe this is getting too complicated and should simplify it ie. find a way to do it without making a second version of the script in /system/xbin.

#!/system/bin/sh
#
# 2 in 1 Engine Flush Script created by zeppelinrox.
#
# The 2 Modes are: Fast Engine Flush Script (which creates, in /system/xbin the...)
# Engine Flush-O-Matic Script
#
# See http://goo.gl/krtf9 - Linux Memory Consumption - Nice article which also discusses the "drop system cache" function!
# See http://goo.gl/hFdNO - Memory and SuperCharging Overview, or... "Why 'Free RAM' Is NOT Wasted RAM!"
#
# Credit imoseyon for making the drop caches command more well known :)
# See http://www.droidforums.net/forum/liberty-rom-d2/122733-tutorial-sysctl-you-guide-better-preformance-battery-life.html
# Credit dorimanx (Cool XDA dev!) for the neat idea to show before and after stats :D
#
# Note 1: To enable "Engine Flush-O-Matic" mode, change the "autoflushon" variable to 1.
# It is automatically enabled and changed to 1 the first time you say yes to enable Flush-O-Matic!
# When first enabled, Fast Engine Flush will copy itself (with a few changes) to /system/xbin/autoflush (Flush-O-Matic version)
# If "autoflushon" is anything other than 1, it's off and won't enter into a "Flush Cycle".
# So... "autoflushon=1" turns it ON. "autoflushon=*anything else*" turns it OFF.
#
# Note 2: If "Engine Flush-O-Matic" is enabled, you can change the "intervalhours" variable to the number of hours you want.
# Valid values are from 1 to 24 (hours).
# If the value is invalid or missing, it defaults to running every 3 hours.
# If "Engine Flush-O-Matic" is disabled (see Note 1), "intervalhours" can be anything and will be ignored anyway lol.
# Example: If you want it to run every 4 hours, make the line read "intervalhours=4".
#
# Usage: 1. Type in Terminal: "su" and enter, "flush" and enter. ("flush" is indentical to !FastEngineFlush.sh but easier to type :p)
# 2. Script Manager: launch it once like any other script OR with a widget (DO NOT PUT IT ON A SCHEDULE!)
#
# Important! Whether you run "flush" with Terminal or Script Manager or widget, close the app after it runs ONCE.
# This is due to the fact that "flush" launches "autoflush" which is what continues in the background.
# Therefore, DO NOT run the Engine Flush-O-Matic ("autoflush") version - since that's the one that stays running!
#
# To verify that it's running, type in Terminal:
# 1. "pstree | grep autoflush" - for usage option 1 (with Terminal)
# 2. "pstree | grep sleep" - for usage option 2 (with Script Manager)
# 3. "cat /proc/*/cmdline | grep autoflush" - Sure-Fire method ;^]
# - This output should be 3 items:
# a. "/system/xbin/autoflush"
# b. "autoflush-Engine_Flush-O-Matic_is_In_Effect!" (sleep message)
# c. "autoflush" (created by your query so this doesn't mean anything)
#
[Android Software/Hacking General [Developers Only]] MarcoToo:
I actually feel like

#flag as non-rotational device
for i in /sys/block/*/queue/rotational
do echo 0 > $i
done

#set higher cache
for i in /sys/block/*/queue/read_ahead_kb
do echo 512 > $i
done

improved overall I/O. But that might actually be because I expected something to happen. :P

And btw, after I couldn't get looping scripts to work…

I ended up doin it this way(the static binary is only 51KB):

//
// daemon.c
//
//
// Created by koneu on 07.01.13.
//
//

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>

int main(int argc, char *argv[]) {

if (argc != 3) {
printf("tiny cron daemon\n");
printf("usage: %s <script> <time(sec)>\n", argv[0]);
exit(EXIT_FAILURE);
}
else {

/* Our process ID and Session ID */
pid_t pid, sid;

/* Fork off the parent process */
pid = fork();
if (pid < 0) {
exit(EXIT_FAILURE);
}
/* If we got a good PID, then
we can exit the parent process. */
if (pid > 0) {
exit(EXIT_SUCCESS);
}

/* Change the file mode mask */
umask(0);

/* Create a new SID for the child process */
sid = setsid();
if (sid < 0) {
/* Log the failure */
exit(EXIT_FAILURE);
}

/* Close out the standard file descriptors */
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);

/* Wait for system startup */
sleep(90);

int time = atoi(&*argv[2]);
pid_t xhild;
char *arg[] = { argv[1], NULL };
int wake_fd;

/* The Cron Loop */
while (1) {
/* Wait for device wake */
wake_fd = open("/sys/power/wait_for_fb_wake", O_RDONLY);
if(wake_fd) {
read(wake_fd, NULL, 0);
close(wake_fd);
}
/* Execute argv[1] in child process */
xhild = fork();
if(xhild == 0) {
execv(arg[0], arg);
}
else {
/* Avoid zombies */
wait(0);
/* Wait argv[2] seconds (main process) before looping again */
sleep(time);
}
}
exit(EXIT_SUCCESS);
}
}
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Interesting. Thanks.

I actually don't have a problem with getting looping scripts to work.

The BulletProof Apps script works great :)

I was just overcomplicating this Engine Flush thing by having one script having to consider too many different scenarios (like if there's one instance already sleeping) with a looping and non-looping version.

So I'm going back to using just one version which will simply give the user the option to turn on or turn off Flush-O-Matic mode after it flushes.

It will simply edit itself (if needed), relaunch in a different instance (if Flush-O-Matic is turned on) and exit.

To get around the issue of the script just sitting there waiting for user input, I put in a 10 second time delay. (a neat trick I kanged from somebody's Die-Hard Calibrator script... thanks zep!)

If there is no input, it continues after the 10 seconds.

I'm almost done a test version that I can post :)
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Ok test this if you like :D

It's self configurable and you can change options every run or ignore the prompt.

Run it the usual way or read the OP lol

ACK! It seems to only accept 1, 2 or 4 hours as input lol

I specified from 1- 24 hrs but I don't think bash understood what I meant :o
[Android Software/Hacking General [Developers Only]] mixednuts:
Lol... didn't give me 10 sec to key in Y or N. Ran fine... ended at Now executing -=Engine Flush-O-Matic=-...
[Android Software/Hacking General [Developers Only]] SgtSausage21:
Tested, seemed to work fine. I looked away while the script loaded and went through everything, came back and saw 10 seconds wasn't sure how long it had been. Couldn't help but get shocked, made it in time though.

I just used 4 hours, cause you said all it would take was 1, 2, or 4, fine with me. :good: :good:
[Android Software/Hacking General [Developers Only]] mixednuts:
yep... "Engine Flush-O-Matic is ON @ 1 hour intervals!"

lol... "Here We Go Again... in 1 hours LOL" :)

EDIT: Just noticed the script stays running, after running it the second time, instead of being killed. Problem?
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Can you elaborate?

I guess you did the verification as written in the comments?

It should stay sleeping (just one instance) in the background... just as 97BulletProof_Apps does.

If the script is run again, it should tell you that FOM is already in memory and refuse to enter into a second FOM cycle.

=================================

Here's a much improved teaser 2...

- Fixed the input... can now do from 1 - 24 hours.

- Added logging with echos to /data/Ran_FastEngineFlush.log

- Much more information/instruction after you enable Flush-O-Matic for the first time.

- Oh yeah... made the input a 20 second time limit instead of 10.

Turns out that on the relaunch (in FOM mode)... it doesn't actually wait anyway lol (but you can always have input with a fresh instance that you run yourself)
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Oh no wonder nobody has commented...

I forgot to actually attach it to the post :o

Right so it's now there in the previous post so please leave feedback :)
[Android Software/Hacking General [Developers Only]] mixednuts:
Haven't tried teaser 2 yet, but when running the script again it doesn't spit out anything about saying it's in memory.... just says that it's ON and gonna run at whatever interval as exactly I quoted in my previous post.

To verify it's running you just run it again, correct?

Oh, when running the script the first time, using Script Manager, the script kills itself at the end of configuration... when running again the script doesn't kill itself.

Again, this is all for the first teaser... I'll report on second when I get a chance.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
I forget if teaser 1 had it but teaser 2 has 2 checks... one at the beginning and one at the end (just in case detection failed the first time or if the first Engine Flush instance wasn't asleep at the time)

When FOM is first enabled, I added this info which probably answers your questions about SM.

echo " You can change options by..."
echo ""
sleep 1
echo " ...running this script again :o)"
echo ""
echo $line
echo ""
sleep 1
echo " Can you close this app now?"
echo " ==========================="
echo ""
sleep 1
echo " If using terminal: YES - after the relaunch."
echo ""
sleep 1
echo " If using Script Manager: after the relaunch..."
echo ""
sleep 1
echo " ...run the script again, hit the Back Button.."
echo ""
sleep 1
echo " ...then click \"Leave in Background\"."
echo ""
sleep 1
echo " ...then close/kill/nuke Script Manager!"

So the second time, you back out of it, click "leave in background" and script m anager can be closed out of memory and FOM will remain running just they way it would if you were using terminal.

Anyway, it's gonna get launched by /init.d/*99SuperCharger so after you turn on FOM once, it will be automatically loaded after each boot.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
2 NEW Test 2s!

The V6 update is a tedious ball breaker... pushing 9,000 lines of code now with all the additions and enhancements...

But I wanted to get something out the door today...

SO... these are pretty much done but why not test them first before adding to official downloads... a little perk, eh?

3GTC has:

- revamped Wi-Fixer! - adding fix permission to wpa_supplicant.conf so maybe it can be fixed without having to create a new .conf file and avoid having to re-enter wifi passwords

- revamped Wi-Fi AfterBurner! - added more tweaks to tiwlan.ini AND if you don't have tiwlan.ini... it will create one (some users report it actually works so why the hell not...)

KAK has:

- a new Entropy-ness Enlarger (that's what she sed!)

- revamped code for IO Tweaks - should be much less problematic and you choose the scheduler!

- enhanced user info/interface/code

- support for newer kernels

- added the 3 reboot tolerance levels

Click Thanks... yada yada yada...
[Android Software/Hacking General [Developers Only]] GermainZ:
ROFL :laugh::laugh::laugh:
[Android Software/Hacking General [Developers Only]] bbrad:
Thanks downloading now
[Android Software/Hacking General [Developers Only]] SgtSausage21:
Can't Wait for V6

Reporting back after testing all 3 latest scripts.

FOM: Teaser 2 ran fine, works great, running on 3 hour schedule.

3GTC: Awesome update, finally can use Wi-Fi afterburning, even without a tiwlan.ini. WOOT! Speeds tests went great as well.

KAK: Mmm. this update completely removed any residue of bubble gum, total Ass Kicking indeed.

V6: Still using Test 10 eagerly waiting for the BIG ONE.

Thanks :good: :D

EDIT: Little late now, sorry, but i always get this error message when running the latest v6 test 10, (doesn't appear on test 9). I never cared because it still works fine, just figured i would share.
[Android Software/Hacking General [Developers Only]] bbrad:
Just used the test kak all I can say is DAMN big improving indeed it officially kicks ass and I can now use the io tweaks WITHOUT boot loop :thumbup:
[Android Software/Hacking General [Developers Only]] SpudsterZ:
Running all three teasers (V6, KAK, 3G) on d2usc CM 10.1 01/15 nightly with leanKernel 2.2 with no fuss, no muss.

No hard testing, but subjectively everything feels smoother and snappier. I could swear I have better 4g signal now too!

Good job, Zep.
[Android Software/Hacking General [Developers Only]] phonetool:
Running the new KAK and 3G scripts. First time on the 3G.

No problems here.

I don't have any speed baselines, so didn't care to run tests.

Another valiant effort, zep! Thanks for everything.

-MROM on DInc2
[Android Software/Hacking General [Developers Only]] Daniel D.:
What should I choose in KAK?
[Android Software/Hacking General [Developers Only]] Computoncio:
Zeppelinrox i found something to you look on kak, choosing kernel levels i choose rock hard and it echos soft rock

Edit: ignore the above, my mistake :rolleyes:

and an mounting error, pics below.

In 3GTurboCharger i didn't find anything, working great as expected :Dun-Turbocharger also clean well.

I'm using your 3 teasers with Resurrection Remix and Dorimanx v7.40 kernel and my phone was never so stable and fast.

Thanks for your hard work :thumbup:

Hope the xda gives you the proper credits soon :D

Edit: When changing settings on kak the mounting error doesn't appear.

Phone: Samsung Galaxy SII - GT-I9100

Kernel: Dorimanx kernel v7.40

1st ROM : RR JB v3.1.3 (Online)

2nd ROM : Empty

MODEM: Modem+RIL - XXLPS

ROOT APP: SuperSu v0.99

MODS: My mods, ASUL v4.2 and JusTunBeam v6.1.3
[Android Software/Hacking General [Developers Only]] Daniel D.:
You did not enter "h", you entered "1"! :)
[Android Software/Hacking General [Developers Only]] bbrad:
Look at the 2nd one -_- that's the error he's talking about
[Android Software/Hacking General [Developers Only]] GermainZ:
"Any key for Soft Rock".
[Android Software/Hacking General [Developers Only]] Computoncio:
Ok kernel level my mistake :rolleyes::p

My weird if the second time i ran the script i clicked h and not 1

:D

Phone: Samsung Galaxy SII - GT-I9100

Kernel: Dorimanx kernel v7.40

1st ROM : RR JB v3.1.3 (Online)

2nd ROM : Empty

MODEM: Modem+RIL - XXLPS

ROOT APP: SuperSu v0.99

MODS: My mods, ASUL v4.2 and JusTunBeam v6.1.3
[Android Software/Hacking General [Developers Only]] Daniel D.:
One question: Why did you add the 3G lines at the top of build.prop? I thought later lines will overwrite the other ones!? :confused:
[Android Software/Hacking General [Developers Only]] zeppelinrox:
heh... thanks for the feedback.

Interesting error... seems there may be something fishy about your build.prop... do this in terminal:

getprop | grep sdk | sed 's/.*\[//' | tr -d ']'

Should be a number... but something about "influence" may show up

Yeah when I was looking at the code with fresh eyes... I saw a facepalm looking back at me.

I ended up redoing pretty much the whole IO part of it with safety checks so if you edit the scheduler, it makes sure that it's a valid scheduler or else it uses the default sio>noop>cfq order.

It also won't apply a scheduler for a block if it's already set to the desired one.

Thanks :)

Thanks for the feedback.

The error actually only applies to one tweak - to /sys/kernel/debug.

Some devices don't even have it.

Any attempt to hide the error fails or causes bootloop... I forget lol I'll try again about hiding it tho :p

99% of the time that's true.

But the other 1% is the ro.* prop entries.

Once those are applied, they cannot be changed.

That's why I added the option to have the ro.*_APP_ADJ priorities to build.prop - because build.prop is loaded before local.prop and supercharging local.prop didn't work alot of the time because of the ro.HOME_APP_ADJ setting in build.prop ;)

And so I put them at the top of build.prop so that I can safely ignore any other ro.* entries and don't have to wipe them from anywhere or worrying about them being anywhere else like setprop commands in some init.d scripts.

All those will have no effect.

I TurboCharge at the top, SuperCharge at the bottom - so I have all bases covered lol
[Android Software/Hacking General [Developers Only]] SgtSausage21:
Results!

Went ahead and ran the command, attached is screenshot of the result.