[Captivate Android Development] kodos96:
So I replied to this back when you first posted it, but just now I went back to look for that reply to refer someone else to it, and can't find it... it looks like it never actually got posted... maybe I didn't hit submit or something? Anyway, let me re-reply now and try to answer your questions:

Well, almost... it means it's at the highest possible priority, so the system shouldn't kill it unless it's already killed everything else and is still out of memory, which shouldn't ever happen unless the kernel or system processes are going crazy.

An app displaying a status bar icon. That's actually why lots of apps display a status bar icon: to "trick" android into not killing them. Also, apps like keyboards which are visible but not the foreground app.

An app that is perceptible via one of the 5 senses other than vision... until such time as Google introduces Smell-O-Vision (TM), that effectively means apps that are playing sound in the background, i.e. music players or turn by turn nav apps.

I'm not entirely sure. I think the intention was to represent apps like web browsers, which are very painful to have to reload... however if that was in fact the intention, then the heuristic they're using for classifying apps as "heavy weight" isn't very effective, because it doesn't seem to help much at keeping apps that I would describe as "heavy weight" from getting killed. I'm still digging through the source trying to figure this one out.

A service is a type of app (or component of an app) that runs in the background, listening for events to respond to, without directly interacting with the user. I'm still a bit fuzzy though on what makes a service count as "secondary"

This seems to refer to an app doing a backup to google's android backup service, which nobody seems to really use... I'm not sure why this deserves an app class all to itself.

Well, because as annoying as it is when your launcher get killed, it's relatively painless compared to most of the app classes that come before it... when your launcher is killed it just has to spend a few seconds reloading the next time you hit the home button... but if your music player got killed in the background, that would really suck. I agree though that it doesn't seem to make sense that it's lower priority than BACKUP and SECONDARY_SERVICE

This just means a user-level app that has been switched away from and is no longer in the foreground... i.e. what most people would think of as a "background app"

An empty app means an app that the user has quit out of via the back button (or an explicit "quit" command in the app), or an app which the user never actually launched in the first place - it's only running because it responded to some system event.

The reason for it being 15 rather than just 7 is that the hidden app value is actually HIDDEN_APP_MIN, i.e. the minimum value for a hidden app... but a hidden app's value gets dynamically adjusted by the system based on a variety of factors like how long it's been running, how long it's been idle, how much ram it's consuming, etc.... so when you first switch away from an app, its score starts out at HIDDEN_APP_MIN, but then that score gets gradually increased as the app "ages" in your cache, and then when the system is low on memory, it starts killing apps with the highest score first.

So EMPTY_APP has to be really high in order to tell the system "don't kill any hidden apps, no matter how high their oom score is, unless you've already killed all the empty apps first"

When the system's free memory reaches one of these MEM thresholds, it starts killing apps of the corresponding ADJ level. So by setting EMPTY_APP_MEM=12288, you're telling the system "when my free ram gets down to 48mb, start killing empty apps", and the line you quoted above tells the system "don't kill the foreground app unless free ram gets all the way down to 8mb"

Basically it just means that the kernel levels should be set to values that actually appear in the list of framework values above... so there are 9 framework values, and 6 kernel values... you should choose your kernel values by picking 6 out of the 9 framework values, rather than just making up new ones.

Which 6 should you pick? I don't know the answer to that question... I don't even know if there is a right or a wrong answer to that question. The interplay between the kernel and framework LMK systems is very complex, and after hours of digging through the code, I still only kind of understand it.

I hope this info is helpful... although keep in mind that none of it should be taken as gospel truth - it's just what I've been able to figure out so far based on reading through the source code, but it's entirely possible I'm wrong about something.