Well I hope it works because this odex stuff on some devices is really annoyingHey thanks dude, I'll give it a try now
Im not too worried if I nail my phone lol, like I say, its a reflash away from being alive again xD
Well I hope it works because this odex stuff on some devices is really annoyingHey thanks dude, I'll give it a try now
Im not too worried if I nail my phone lol, like I say, its a reflash away from being alive again xD
Ends at this point, goes no further.Installing dexopt-wrapper to /system/bin...
1076 KB/s (5512 bytes in 0.005s)
==========================================================
Running baksmali to decompile and get smalis...
Backing up files to \backup folder...
1 file(s) copied.
The system cannot find the file specified.
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
Copying smali files needed for patching...
1 file(s) copied.
The system cannot find the file specified.
==========================================================
About to run Ultimate Jar Power Tools...
==========================================================
Press the enter key when ready...
==========================================================
[sig] C:\Users\Joe\AppData\Local\qbA119560.CD\sh.exe 1000 (
0) call_handler: couldn't get context of main thread, error
998
oh it may be something wrong with the exe lemme check it outNo luck again buddy Thanks very much for trying though, I'll keep trying see if I can push it in the right direction, heres the output so far:
Ends at this point, goes no further.
Do you think its worth simply deodexing my ROM?
Script manager ran fine before?I was following this tutorial: http://xdaforums.com/showthread.php?t=1603953
When I finished part II, I try to run Script Manager I get FC. What can I do? :/
Yeah try admin but I also attached a batch file version in my prior post.
How can i manually select nova launcher as default launcher
Sent from my GT-19100G using Tapatalk 2
No I'm not junking anything.
First thing's first - gotta refine the mod so that the memory management isn't hampered and works how it's supposed to while supercharging the launcher and I'm pretty sure I have it now.
Some parts of the code should indeed stay the same such as the memory trimming and the calculation to determine if there is a lowMem condition.
In the source, they specify the memory level belonging to home.
But in the smali, what matters is the memory level belonging to ADJ 6.
So if I leave that alone, it's still working the way that it's supposed to - using the memory level corresponding to ADJ 6 - it doesn't matter if ADJ 6 belongs to home or server apps - as long as it's using the right memory level to determine a lowMem condition.
static int oomAdjToImportance(int adj, ActivityManager.RunningAppProcessInfo currApp) {
if (adj >= ProcessList.HIDDEN_APP_MIN_ADJ) {
if (currApp != null) {
currApp.lru = adj - ProcessList.HIDDEN_APP_MIN_ADJ + 1;
}
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND;
} else if (adj >= ProcessList.SERVICE_B_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE;
} else if [B](adj >= ProcessList.HOME_APP_ADJ)[/B] {
if (currApp != null) {
currApp.lru = 0;
}
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND;
} else if (adj >= ProcessList.SERVICE_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE;
} else if (adj >= ProcessList.HEAVY_WEIGHT_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_CANT_SAVE_STATE;
} else if (adj >= ProcessList.PERCEPTIBLE_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_PERCEPTIBLE;
} else if (adj >= ProcessList.VISIBLE_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_VISIBLE;
} else {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND;
}
}
Same goes for trimming apps - it wants to trim apps according to the memory level corresponding to particular ADJs - and it don't matter what group that ADJ belongs to.
if (app.nonStoppingAdj >= ProcessList.HOME_APP_ADJ
&& app.nonStoppingAdj != ProcessList.SERVICE_B_ADJ
&& !app.killedBackground) {
numTrimming++;
}
That's probably why the smali is coded that way. It doesn't grab the ADJ all the time from ProcessList and instead sets a value each time.
The only ADJ that can be changed once and it will have an effect everywhere is HIDDEN_APP_MIN_ADJ.
It gets fetched from ProcessList every time.
So that's THE the setting that everything else revolves around.
So in other places, ADJs can be changed so long as it doesn't have a bearing on things like trimming memory or killing background tasks.
Of course, after patching services.jar, if it wants to trim ADJs 6 or 7... it will be still be trimming those same ADJs - but it will be trimming server and backup groupings instead of home and previous app.
if (a >= 1)
return 1;
else if (a >= 2)
return 2;
else if (a >= 3)
return 3;
You don't like that idea but that's the whole point of SuperCharging the launcher - it don't get killed until it's needed to get killed
So the apps you used awhile ago get killed before the launcher instead of the other way around.
And like I said before - it's entirely possible to customize ProcessList.smali to put the minfrees you want in there by changing the first array - and disabling the scaling factor.
No need to mess with the second array because with scaling disabled, the first array gets applied as is.
mOomMinFree[i] = (long)(low + ((high-low)*scale));
I previously mentioned that I'm fixing all those if/else conditions.Sorry for the late reply. Lots of activities nearing Christmas I only had the time to look at the replies via Tapatalk and can't get a hold of my laptop.
It's comparing the ADJ not the memory. Take this code for example:
Code:static int oomAdjToImportance(int adj, ActivityManager.RunningAppProcessInfo currApp) { if (adj >= ProcessList.HIDDEN_APP_MIN_ADJ) { if (currApp != null) { currApp.lru = adj - ProcessList.HIDDEN_APP_MIN_ADJ + 1; } return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND; } else if (adj >= ProcessList.SERVICE_B_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE; } else if [B](adj >= ProcessList.HOME_APP_ADJ)[/B] { if (currApp != null) { currApp.lru = 0; } return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND; } else if (adj >= ProcessList.SERVICE_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE; } else if (adj >= ProcessList.HEAVY_WEIGHT_APP_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_CANT_SAVE_STATE; } else if (adj >= ProcessList.PERCEPTIBLE_APP_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_PERCEPTIBLE; } else if (adj >= ProcessList.VISIBLE_APP_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_VISIBLE; } else { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND; } }
If HOME_APP_ADJ is 1, almost every app that is evaluated will practically be returned an LRU (least recently used) of 0 and be kept in memory the same priority as the launcher. This would practically nullify the goodness of having an ADJ of 1 at all.
ya but that's a memory trimming routine. So I left that as is so it effects server apps instead of home.Code:if (app.nonStoppingAdj >= ProcessList.HOME_APP_ADJ && app.nonStoppingAdj != ProcessList.SERVICE_B_ADJ && !app.killedBackground) { numTrimming++; }
It's compares the ADJ, not the memory level of the ADJ.
as peviously stated I made changes on a case by case basis while looking at the big picture.smali files are disassembled files that can be assembled to be directly read as bytecode operations by Dalvik (that much I've read and understood and now fully understand what you meant by changings in the smali that won't affect trimmings etc). However, if you choose some to be applied as 0x6 (the default HOME_APP_ADJ) and some as 0x1 (the modified HOME_APP_ADJ), you basically won't get the goodness of a "Hard to Kill" Launcher. This is because the algorithm itself that makes it harder to kill is also the one that effectively disable Android LMK.
Note that the HIDDEN_APP_MIN_ADJ did not get compiled as a constant when compiled into Dex largely because Dex compiler might've noticed that the value might change or can be subjected to change later in other functions (maybe). the point of bytecode operations and constants is so that Dex can be loaded faster/ran faster.
Have you ever seen post 2? Youre nearly a year behind plus you're telling me what ive taught you.You do know that memory trimmings/ OOM/ LRU adjusts are the ones that directly make the Launcher hard to kill right?
I.e.
You change the HOME_APP_ADJ in ProcessList but you don't change the HOME_APP_ADJ in ActivityManagerService. This literally mean that the value in ProcessList only exists there. It doesn't get called like HIDDEN_APP_MIN_ADJ does. If you decide to change it in ActivityManagerService, you'll get a half-baked LMK.
so what part of "I fixed the if conditions" is confusing?That's because some values will be evaluated in a nested if/else then the others are skipped. It's basically like this code
Code:if (a >= 1) return 1; else if (a >= 2) return 2; else if (a >= 3) return 3;
The problem is when you changed a to become 1, you'll basically render the other conditions invalid ALL THE TIME.
wrong again.You don't need Supercharger. You just need a "Keep App in Memory" option in most major launchers out there. This will effectively make the launcher harder to kill. Though, if you Supercharge your phone, you'll break this functionality as "Keep App in Memory" relies on the original OOM adjustments to work.
No.I forgot to tell you, yes, it's possible to customize the minfrees in ProcessList.smali. You'll have to make sure that Low is 0KB in all of them and then set the high:
Code:mOomMinFree[i] = (long)(low + ((high-low)*scale));
Correction.You can't however, adjust the ADJs without breaking something in the end.
The only reason that you think that is because you don't listen and because you think that you know everything already.After some very long winded discussion with you, I find that you really don't know what you're doing nor you have much knowledge about how Android LMK really works. I'm pretty saddened to learn about this. Nonetheless, I appreciate your tenacity and if you're interested to better the experience of Android phones, you should learn to own up to your mistakes and accept criticisms, especially the ones that questions your own self imposed principles, the ones that you tell other people to follow but don't follow it yourself.
Let me know if you need help in what edits to make in your smali. I may have only learned about it, but I do think that I now know much more about it than you judging from your replies from the past few days that pretty much shows how much you know about it.
Do I need to run supercharger in script manager or just put it in init.d folder will work?
I'm using in i9300.
Just to cut to the chase...And Zepp just proved that pokemon are LAME!
After reading this discussion, I've understood nearly none of it other than this:
Any answer given by pokeboy was proven incorrect or partially incorrect. The partially incorrect statements were then corrected and in some cases implemented. Zepp gladly admits he was incorrect, see some of his responses. Pokeboy on the other hand, you dismiss anything that has been stated by Zepp with blissful ignorance.
The proof is in the pudding, in this case, SuperCharger! It works. Get over it.
Clay
Team Pirate
Sent from my Galaxy SHOswagger2
for (int i=list.size()-1; i>=0; i--) {
ProcessRecord r = list.get(i).first;
String oomAdj;
if (r.setAdj >= ProcessList.HIDDEN_APP_MIN_ADJ) {
oomAdj = buildOomTag("bak", " ", r.setAdj, ProcessList.HIDDEN_APP_MIN_ADJ);
} else if (r.setAdj >= ProcessList.SERVICE_B_ADJ) {
oomAdj = buildOomTag("svcb ", null, r.setAdj, ProcessList.SERVICE_B_ADJ);
} else if (r.setAdj >= ProcessList.PREVIOUS_APP_ADJ) {
oomAdj = buildOomTag("prev ", null, r.setAdj, ProcessList.PREVIOUS_APP_ADJ);
} else if (r.setAdj >= ProcessList.HOME_APP_ADJ) {
oomAdj = buildOomTag("home ", null, r.setAdj, ProcessList.HOME_APP_ADJ);
} else if (r.setAdj >= ProcessList.SERVICE_ADJ) {
oomAdj = buildOomTag("svc ", null, r.setAdj, ProcessList.SERVICE_ADJ);
} else if (r.setAdj >= ProcessList.BACKUP_APP_ADJ) {
oomAdj = buildOomTag("bkup ", null, r.setAdj, ProcessList.BACKUP_APP_ADJ);
} else if (r.setAdj >= ProcessList.HEAVY_WEIGHT_APP_ADJ) {
oomAdj = buildOomTag("hvy ", null, r.setAdj, ProcessList.HEAVY_WEIGHT_APP_ADJ);
} else if (r.setAdj >= ProcessList.PERCEPTIBLE_APP_ADJ) {
oomAdj = buildOomTag("prcp ", null, r.setAdj, ProcessList.PERCEPTIBLE_APP_ADJ);
} else if (r.setAdj >= ProcessList.VISIBLE_APP_ADJ) {
oomAdj = buildOomTag("vis ", null, r.setAdj, ProcessList.VISIBLE_APP_ADJ);
} else if (r.setAdj >= ProcessList.FOREGROUND_APP_ADJ) {
oomAdj = buildOomTag("fore ", null, r.setAdj, ProcessList.FOREGROUND_APP_ADJ);
} else if (r.setAdj >= ProcessList.PERSISTENT_PROC_ADJ) {
oomAdj = buildOomTag("pers ", null, r.setAdj, ProcessList.PERSISTENT_PROC_ADJ);
} else if (r.setAdj >= ProcessList.SYSTEM_ADJ) {
oomAdj = buildOomTag("sys ", null, r.setAdj, ProcessList.SYSTEM_ADJ);
} else {
oomAdj = Integer.toString(r.setAdj);
}
static int oomAdjToImportance(int adj, ActivityManager.RunningAppProcessInfo currApp) {
if (adj >= ProcessList.HIDDEN_APP_MIN_ADJ) {
if (currApp != null) {
currApp.lru = adj - ProcessList.HIDDEN_APP_MIN_ADJ + 1;
}
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND;
} else if (adj >= ProcessList.SERVICE_B_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE;
} else if (adj >= ProcessList.HOME_APP_ADJ) {
if (currApp != null) {
currApp.lru = 0;
}
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND;
} else if (adj >= ProcessList.SERVICE_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE;
} else if (adj >= ProcessList.HEAVY_WEIGHT_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_CANT_SAVE_STATE;
} else if (adj >= ProcessList.PERCEPTIBLE_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_PERCEPTIBLE;
} else if (adj >= ProcessList.VISIBLE_APP_ADJ) {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_VISIBLE;
} else {
return ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND;
}
}
But this quote isn't quite right either. Looking at the second screen shot, every app would have a weaker condition than they should, not a stronger one.If HOME_APP_ADJ is 1, almost every app that is evaluated will practically be returned an LRU (least recently used) of 0 and be kept in memory the same priority as the launcher. This would practically nullify the goodness of having an ADJ of 1 at all.
private void updateOomLevels(int displayWidth, int displayHeight, boolean write) {
// Scale buckets from avail memory: at 300MB we use the lowest values to
// 700MB or more for the top values.
float scaleMem = ((float)(mTotalMemMb-300))/(700-300);
// Scale buckets from screen size.
int minSize = 320*480; // 153600
int maxSize = 1280*800; // 1024000 230400 870400 .264
float scaleDisp = ((float)(displayWidth*displayHeight)-minSize)/(maxSize-minSize);
//Slog.i("XXXXXX", "scaleDisp=" + scaleDisp + " dw=" + displayWidth + " dh=" + displayHeight);
StringBuilder adjString = new StringBuilder();
StringBuilder memString = new StringBuilder();
float scale = scaleMem > scaleDisp ? scaleMem : scaleDisp;
if (scale < 0) scale = 0;
else if (scale > 1) scale = 1;
for (int i=0; i<mOomAdj.length; i++) {
long low = mOomMinFreeLow[i];
long high = mOomMinFreeHigh[i];
mOomMinFree[i] = (long)(low + ((high-low)*scale));
if (i > 0) {
adjString.append(',');
memString.append(',');
}
adjString.append(mOomAdj[i]);
memString.append((mOomMinFree[i]*1024)/PAGE_SIZE);
}
I previously mentioned that I'm fixing all those if/else conditions.
ya but that's a memory trimming routine. So I left that as is so it effects server apps instead of home.
I went over it top to bottom and fixed everything that didnt "add up".
as peviously stated I made changes on a case by case basis while looking at the big picture.
As for the hidden app min adj, its treated different because they always put it in the static construcor in processlist.smali.
Its intentional.
Some roms put max hidden apps in the constuctor so to change max hidden apps in those roms, only 1 edit is needed and gets applied everywhere just like hidden app min adj.
class B {
static int a = 1;
}
Have you ever seen post 2? Youre nearly a year behind plus you're telling me what ive taught you.
And how can it be half baked when you just said the processlist entry has no effect?
As for what diectly makes the launcher hard to kill, read post 2 because you no idea that it already supercharges because youve never actually supercharged.
so what part of "I fixed the if conditions" is confusing?
wrong again.
If you ever read page 1, you'd know that "keep home in memory" merely gives the launcher the same ADJ as visible apps on pre-ics roms.
Now it applies a ADJ 2 on ICS and JB.
Ever read anywhere that you can use that keep home in memory featue as a tool to make the launcher weaker if needed?
Please... do your homework.
You don't have the experience so now you're spreading misinformation due to ignorance.
Clearly, you're not qualified to speak about that topic.
No.
I make the scale 0 and the only thing left in the equation is the low value - the lower set of minfrees ie. the first array.
The only reason that you think that is because you don't listen and because you think that you know everything already.
I just proved you wrong.
You don't know everything.
I don't have the time to look at it. Please paste the code into your post so that I can see it.The test zips I posted yesterday actually have the new changes.
Compare before and after smalis.
You wont find anything broken, and that's a fact.
Talk after patching your services.jar.
Otherwise, whatever you say about it will be all wind with no real experience to back up your hypothesis.
Just to cut to the chase...
This code:Looks like:Code:for (int i=list.size()-1; i>=0; i--) { ProcessRecord r = list.get(i).first; String oomAdj; if (r.setAdj >= ProcessList.HIDDEN_APP_MIN_ADJ) { oomAdj = buildOomTag("bak", " ", r.setAdj, ProcessList.HIDDEN_APP_MIN_ADJ); } else if (r.setAdj >= ProcessList.SERVICE_B_ADJ) { oomAdj = buildOomTag("svcb ", null, r.setAdj, ProcessList.SERVICE_B_ADJ); } else if (r.setAdj >= ProcessList.PREVIOUS_APP_ADJ) { oomAdj = buildOomTag("prev ", null, r.setAdj, ProcessList.PREVIOUS_APP_ADJ); } else if (r.setAdj >= ProcessList.HOME_APP_ADJ) { oomAdj = buildOomTag("home ", null, r.setAdj, ProcessList.HOME_APP_ADJ); } else if (r.setAdj >= ProcessList.SERVICE_ADJ) { oomAdj = buildOomTag("svc ", null, r.setAdj, ProcessList.SERVICE_ADJ); } else if (r.setAdj >= ProcessList.BACKUP_APP_ADJ) { oomAdj = buildOomTag("bkup ", null, r.setAdj, ProcessList.BACKUP_APP_ADJ); } else if (r.setAdj >= ProcessList.HEAVY_WEIGHT_APP_ADJ) { oomAdj = buildOomTag("hvy ", null, r.setAdj, ProcessList.HEAVY_WEIGHT_APP_ADJ); } else if (r.setAdj >= ProcessList.PERCEPTIBLE_APP_ADJ) { oomAdj = buildOomTag("prcp ", null, r.setAdj, ProcessList.PERCEPTIBLE_APP_ADJ); } else if (r.setAdj >= ProcessList.VISIBLE_APP_ADJ) { oomAdj = buildOomTag("vis ", null, r.setAdj, ProcessList.VISIBLE_APP_ADJ); } else if (r.setAdj >= ProcessList.FOREGROUND_APP_ADJ) { oomAdj = buildOomTag("fore ", null, r.setAdj, ProcessList.FOREGROUND_APP_ADJ); } else if (r.setAdj >= ProcessList.PERSISTENT_PROC_ADJ) { oomAdj = buildOomTag("pers ", null, r.setAdj, ProcessList.PERSISTENT_PROC_ADJ); } else if (r.setAdj >= ProcessList.SYSTEM_ADJ) { oomAdj = buildOomTag("sys ", null, r.setAdj, ProcessList.SYSTEM_ADJ); } else { oomAdj = Integer.toString(r.setAdj); }
Afterwards, it looks like this:
Ok that looks perfect.
This code:Looks like:Code:static int oomAdjToImportance(int adj, ActivityManager.RunningAppProcessInfo currApp) { if (adj >= ProcessList.HIDDEN_APP_MIN_ADJ) { if (currApp != null) { currApp.lru = adj - ProcessList.HIDDEN_APP_MIN_ADJ + 1; } return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND; } else if (adj >= ProcessList.SERVICE_B_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE; } else if (adj >= ProcessList.HOME_APP_ADJ) { if (currApp != null) { currApp.lru = 0; } return ActivityManager.RunningAppProcessInfo.IMPORTANCE_BACKGROUND; } else if (adj >= ProcessList.SERVICE_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_SERVICE; } else if (adj >= ProcessList.HEAVY_WEIGHT_APP_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_CANT_SAVE_STATE; } else if (adj >= ProcessList.PERCEPTIBLE_APP_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_PERCEPTIBLE; } else if (adj >= ProcessList.VISIBLE_APP_ADJ) { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_VISIBLE; } else { return ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND; } }
Afterwards, it looks like this:
gah! That's totally fubarred lol... I have to revert this part.
Because of how the logic is structured, if I leave it alone, home at ADJ 1 automatically gets preferential treatment while everything else is treated the way it should be.But this quote isn't quite right either. Looking at the second screen shot, every app would have a weaker condition than they should, not a stronger one.
So that last example shows perfectly that some areas need to be left alone since those areas automatically treat the ADJ properly regardless of what app type uses that ADJ.
Howabout a bonus round.
For ProcessList.smali, the code to determine the scaling factor and minfrees:Looks like:Code:private void updateOomLevels(int displayWidth, int displayHeight, boolean write) { // Scale buckets from avail memory: at 300MB we use the lowest values to // 700MB or more for the top values. float scaleMem = ((float)(mTotalMemMb-300))/(700-300); // Scale buckets from screen size. int minSize = 320*480; // 153600 int maxSize = 1280*800; // 1024000 230400 870400 .264 float scaleDisp = ((float)(displayWidth*displayHeight)-minSize)/(maxSize-minSize); //Slog.i("XXXXXX", "scaleDisp=" + scaleDisp + " dw=" + displayWidth + " dh=" + displayHeight); StringBuilder adjString = new StringBuilder(); StringBuilder memString = new StringBuilder(); float scale = scaleMem > scaleDisp ? scaleMem : scaleDisp; if (scale < 0) scale = 0; else if (scale > 1) scale = 1; for (int i=0; i<mOomAdj.length; i++) { long low = mOomMinFreeLow[i]; long high = mOomMinFreeHigh[i]; mOomMinFree[i] = (long)(low + ((high-low)*scale)); if (i > 0) { adjString.append(','); memString.append(','); } adjString.append(mOomAdj[i]); memString.append((mOomMinFree[i]*1024)/PAGE_SIZE); }
After disabling the scaling, it looks like:
All those changes in the last example are achieved with a single "#" placed in the right place
As you can see, some things can't be changed or the logic is thrown out of whack.
Plus, the fact is, by leaving those areas alone, ADJs are automatically treated as they should be simply because the smali files are always acting on the ADJ regardless of what app type is associated to that ADJ.
While other things, like the first example, needs to be changed.
Actually no.Leaving it as is (like the memoryTrimming function) is the one that will make the Launcher not Supercharged. You do realize that the ADJ values are not passed to the app, but rather the lowMemory, threshold and a few other thresholds (hiddenApp, secondaryServer, visibleApp, foregroundApp).
Here's how the code works:
- ADJs are set in ProcessList
- ADJs are passed to ActivityManagerService and how killable/unkillable an app is, is determined in the memoryTrimmings and LRU calculations. The function oomAdjToImportance basically calculates the importance of an app (to determine whether it should be less killable or not. Leaving that function as is will basically make your launcher unsupercharged.
And you totally miss the point.Do you even know what constructors are or not =_=.
Constructors are routines that are executed when the class is instantiated. The correct definition is "Class Definition" where each variable/method is defined.
And you're wrong in it being static. All other variables for other ADJs are also static. It's the "final" keyword that is absent from HIDDEN_APP_MIN_ADJ (final keyword denoting that the value is not able to be changed after the class is instantiated).
Here's a programming 101 for you:
- static means after the class is instantiated, any changes to static value will change all values of the same name for all classes. E.g.
If I instantiated two new classes of B called B1 and B2, changing the a variable of B1 will change it in B2.Code:class B { static int a = 1; }
- final means that once the class is instantiated, the value of the variable cannot be changed. If the variable is a pointer, the pointer cannot be changed. It's basically a constant. Hence what I mean by "maybe" the value can be changed later (I don't see it being changed, but an App can import ProcessList, instantiate a class out of it and change the value later. Who knows.
The smali edits are localized. That means, if variable has a "final" keyword, all the values that are used are stored as constants (something you've said as true in a few posts earlier). This means that changing only ProcessList will not yield any difference (for all ADJs except HIDDEN_APP_MIN_ADJ).
#the value of this static final field might be set in the static constructor
.field static final MAX_HIDDEN_APPS:I = 0x0
.method static constructor <clinit>()V
.registers 7
.prologue
.line 42
const/16 v1, 0x9
sput v1, Lcom/android/server/am/ProcessList;->HIDDEN_APP_MIN_ADJ:I
Oh I thought you said earlier that those are actually passed to AMS?The definition of Supercharged is that HOME_APP_ADJ is 1 right? HOME_APP_ADJ is a constant and will be instantiated as its own constant in the smalis. It is not referenced like HIDDEN_APP_MIN_ADJ. I didn't read your long winded scripts, but if you've only changed the ProcessList before our discussion, that means your services.jar is basically unchanged (except for HIDDEN_APP_MIN_ADJ if you've changed it).
Why do you speak as if you know?I've never mentioned that "Hard-to-Kill" meant having an OOM_ADJ of 1. Having a 2 or 3 is fine too. The crux of this is that if you enable Supercharger (and you change how LRU and/or mem trimmings work, even if you have "Keep Home in Memory", the Android OOM goodness wouldn't be applied to it (only the Linux LMK which is a hard-ruled process killer without regards of what app it is). That would mean it is half-baked.
Umm, try this. After you've Supercharged i.e. HOME_APP_ADJ to 1, check all the apps OOM_ADJ. Do you see something wrong there?
Hey, if you, or anybody, makes sense, I listen.Au contraire, you're the one that is spreading misinformation. Had I not told you about Supercharger being half-baked, would you even realize that you're breaking your own principle of not offering half-baked LMK/OOM fixes?
no kidding
I proved that you were wrong about your misinformation about supercharging breaking the "keep home in memory" feature that some launchers have.I see you've provided a source code on your later replies. I'll reply there and see if you can learn something from it
How have you proven it? Until now the discussion was me pointing out your mistakes and you saying that you can fix it.
I don't have the time to look at it. Please paste the code into your post so that I can see it.
Post 2 is the actual edits to supercharge the launcher but obvsiously there's alot more than those now.I am yet to see the other post. If you've successfully did it, I'll do a slow clap in the end. I'm not a person who never admits his/her own mistakes.
And no, I don't think I will be patching services.jar. My view is that apps should be the one that handles the OOM priorities.
I've provided the source code for everything I've talked about so far. I have yet to see the source code for your 2nd post. Let's see what you've done so far before I comment on it.
The 8 is Service B apps.Why is your Perceptible more important than your Visible. That makes no sense whatsoever. That means, you're prioritizing killing your Browser first then only your Music Player?
Also, putting a constant of 8 for HIDDEN_APP_MIN_ADJ means that if apps would change that value, it would mismatch with the constant you're putting out there?
Ya, thanks for confirming
The launcher stays SuperCharged - no matter what.Re-read my quote again. I didn't mention it as weaker or stronger. I'm saying that every app will have the same LRU as the launcher.
That code itself determines the importance value of the app that is evaluated. It's the one that makes the app "Supercharged" as you may say. If you leave it un-edited, you would not make it "Supercharged". Please re-read this sentence in order to not counter yourself in the future. I.e. your two choices:
- Put HOME_APP_ADJ to 1 in the importance:
-- You practically screw up the LRU
- Don't put HOME_APP_ADJ to 1 in the importance:
-- You practically don't have a Supercharged launcher
And the launcher stays supercharged while not mixing up the if/else conditions.This is correct.
The AMS service is acting on the memory of the ADJ rather than the ADJ. Remember again that the ADJ is not passed to the app? The two things evaluating the ADJs are the oomAdjToImportance and the memory Trimmings.
The app evaluates the thresholds and lowMemory.
Main Download Page is HERE (V6 SuperCharger and all the latest RC/Beta/Tests for Kick Ass Kernelizer, 3G TurboCharger, and Die-Hard Battery Calibrator)
Latest V6 SuperChargers are Black Dog-63457-Fix and For Your Lag
Latest KAK and 3G TC are HERE
Post #2 Info! - This is for the application of the following 3 Mods to services.jar!
Mod 1. ICS and Jelly Bean - require the Jelly ISCream Mod done in conjunction with the V6 SuperCharger Script to SuperCharger your launcher!
Mod 2. Froyo and up - can have the New Maximum MultiTasking Mods (Maximum Overdrive and the Time Killer Killer)
Mod 3. Sense 4 and up - remove the Sense 4 limit of only 8 visible apps with the Non-Sense App Limit!
These 3 mods are applied with my:
-=Ultimatic Jar Patcher Tools=- (fully automated exe/bat/sh tools) OR...
-=Ultimate Jar Power Tools=- patcher script (formerly called Jelly ISCream Smali Patcher) to automate Step 5 in Post #2 - the smali edits
Note: The webapp needs updating (aka the "Automatic Transmission" in V6 SuperCharger) and won't work on JB!
System -16 (stock)
Persistent Process -12 (stock)
ForeGround app 0 (stock)
Home Launcher 1 (Die-Hard Launcher) (stock=6)
Perceptible app 2 (stock)
Visible app 3 (stock=1)
Heavyweight app 4 (stock=3)
Previous app 5 (stock=7)
Service 6 (stock=5)
Backup app 7 (stock=4)
Service_b 8 (stock)
Hidden app min 9 (stock)
Hidden app max 15 (stock)
Now copy /sdcard/services.odex to /system/framework and overwrite the original (backed up, yes?) services.odexCreate a new services.odex file from the new services.jar file:
In terminal, type: cd /sdcard, enter, dexopt-wrapper services.jar services.odex $BOOTCLASSPATH, enter.
Here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
Hint: the file size of the new services.odex file should not change!
In terminal, type: busybox dd if=/system/framework/services.odex of=/sdcard/services.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
fixed disappearing apps in zipalign/fixalign scripts (and no more problematic/skipped apps)
fixed frandom
fixed crosslink error in 99SC.sh
fixed bug when configuring boot options from within zepalign, fixfc and fixalign scripts
fixed bug in sdcard calculation
added frandom check
added 6i9 ass easter egg
added vm.vfs_cache_pressure=10
removed pm.sleep_mode
moved config options in boot scripts to the end (after script runs)
/init.d/92vac opens bootlog if no sqlite3 binary
/init.d/93zepalign and /init.d/95fixalign opens bootlog if no zipalign binary
ask before bp launcher
v6 does not run if running from int.d (duh)
tweaked FOM output/stats/user info
tweaked logic when resupercharging re. getting previous options/regenerating
tweaked launcher function (updated whenever you return to menu)
tweaked ram function
enhanced user infos and help file...
...example: Notes about init.d scripts making BootLogs
tweaked lots of code to be more efficient...
...example: No more `cat /file/name | awk or grep` (just awk or grep a file directly... duh...)
Hell... tons of code tweaking anyway lol
Fixed Fixalign and Fix Emissions Bugs
Couple of other smaller bugs