And I get what your saying. I just wondered if they kept the same ratio/%'s when upgrading hardware and the likes. I would assume they would but had no clue. b/c if they didn't then it could be false marketing to say you have X free when n theory you could have a slug phone possibly.
I know im speaking extremes, just wondered if/why never seen #'s on % set asside for certain parts of the hardware ya know.
OK, maybe I only thought I understood what you were saying.
then it could be false marketing to say you have X free when n theory you could have a slug phone possibly
Are you saying that instead of 1 GB free you only have 800 MB free here?
If so - two things: first, they never spec'd free, second, are you counting free as anything free for Android (including user apps to use), after hardware and then coming to 800 GB?
The set-asides for the hardware are a function of Linux and the bootloader as well as the hardware.
Linux may set some aside on the top (in the case of use believing that display, it's 200 MB) - but it also always sets some aside on the bottom - there are set-asides at the bottom on the order of 24 MB and then another 30 MB (so your phone can't be running hog apps until it crashes and you can't get calls or can't recover from hog apps). In my mind, set-asides are set-asides, so it's all the same.
I think you'll find the top/hardware set-asides will vary by software update and roms (it even varies by the tool used to report it without changing anything else).
Maybe the simple answer is simple - you never see set aside here (or in desktop Linux, OS X, or Windows) because that's just an efficiency.
In cases where a GPU or other hardware absolutely going to "steal" memory to work, those are fixed numbers per revision.
If you look at older desktop machines using the Intel GMA 950 gpu, it would get an allocation after loading enough of the OS to support whatever resolution your monitor had. (And if you study that gpu, you know it's set aside is going to be 144 MB, minimum.) And if there were a video processor, it would get its own buffer, too.
Here's a quote from Apple's support website discussing the same issue:
Depending on the application or task being accomplished, Mac OS X may make additional main memory available to the graphics processor for texture use beyond the base amount mentioned above. The most common types of applications that request more system memory to be used as graphics memory are 3D and graphics-intense applications. Using an extended desktop or mirrored desktop may also increase the amount of system memory used as graphics memory.
I guess what I'm trying to say is that in the old days, functions were fixed, things could be clearly spec'd.
With GUI operating systems, things got entangled, then with dedicated GPUs, things got more entangled, then with "3D games" (not even getting to real 3D) things got more entangled still - and so forth.
Now - I say this in honesty, not sarcasm - maybe I'm so used to this, I'm drinking the Kool-Aide. Maybe I dispense it.
Programmers and system designers (that would be me, too) go like this:
Look! RAM! Ooooh - shiny! Wonder how much I can use to provide this cool feature and impress users? (Yes - we literally think that way (although some try to hide it).)
How we got into this was coming from the same direction, and maybe this is semantics.
I haven't tinkered with either the Sensation or the 3vo - but I know things about operating systems and processor cores. And my gut told me right out that with all of the improvements, I wondered if the Sensation isn't running a bit close to the wind with only 768 MB, so I feel more comfortable with 1 GB.
Marc said it simply and best -
marctronixx said:
realize many people will be using the dual camera capability of this gadget. the camera on the evo is ram intensive and battery intensive, along with GPS usage, so factor that X 2 for the 3D portion of this new gadget and additional RAM is welcomed.
I don't think they don't know the set asides or are being dishonest about them - I think they're just specifying the minimum required based on bare metal.
The list of set-asides is likely to be large, and will vary based on user configuration (they can't control that), and OS changes on Google's side (they can't control that).
Set-asides are hidden in plain sight - whether it starts by telling by telling that the device has 800 MB ram, or says Android System uses x% of memory, or process probes say various shared libraries under the hood are using a, b, or c% or memory - so, in my mind, set-asides are set-asides, they're all the same.
In that picture above, the 400+ MB of "used memory" included other set-asides, lots of them.
Do we know if those set-asides are same, less or more than the initial 200 MB set-asides?
Honest question - do we care?