Originally Posted by Frisco
I can see that as a huge influence.. but I'm trying to wrap my mind around it taking over across so many manufacturers, with no (that I can see) carrier/provider resistance (meaning, "give us back one of our best marketing blings, you guys: this is basic Android stuff, we're not Apple.. blah etc").
Excellent point - how did we get here?
I think we know what happened and I'm pretty sure we can say how it happened - but why it happened? That I don't know.
You and I have discussed the apps to sd card debacle before and how, thanks to no user root out of the box, we can't change allocations. I've since refined our previous discussion and updated it for Jellybean, I'll quote it here to save a jump -
Originally Posted by EarlyMon
What I want, no one makes -
- Sufficient storage so I don't have to manage one single thing, or, as little as possible, much, much less than now.
- All user storage accessed via USB mass storage, no more MTP, no more special PC add-ons to get to my stuff - all accessible with the world's simplest USB driver for any Windows, and no add-ons for a Mac or Linux PC.
- This can be done with an extra software layer between the USB port and memory storage, so stop telling me how hardware works, you manufacturers. If you can not figure how to apply an internal client/server model for that, pay me, I'll do it for you.
- And you can still share storage while connected, just like MTP, only without the Mickey Mousing around.
- Don't tell me that my internal storage has to be FAT32 to be accessed via USB storage. With a client/server model and a hardware buffer or two, that's not true.
- If there must be separate partitions for /data (where user apps+data go) and user storage, then give me a slider that I can use any time to raise one, lower the other
- If that's all one partition, fine. Do not break it into folders and hold my hand with MTP. Did I mention that I hate MTP? Because it basically sucks?
- No more bragging about how they've done me a favor with the new age of Honeycomb/ICS/Jellybean storage. The file system models are not modern, they're still stone age, better alternatives exist, fix it.
- Oh, yes you can span internal storage and an external card and address it all as one filesystem as far as the user is concerned. Advanced Linux platforms do this every single freaking day. Don't tell me you can't.
- Give me that with options that include 96 and 128 GB.
- If you want to use a card for that, fine. How about making the device recognize SDXC/UHS-1 instead of just SDHC/Class 10 and letting me triple my bandwidth?
- This just in, we're all sick and tired of hearing that widgets cannot go on to the sd card because of boot-time mounting issues and sd card speed. Fix it, we've only been complaining for years about that.
Except for one component described above, and I could be wrong on even that not already laying around somewhere, all of the technology I describe _exists_.
But it doesn't exist on a smartphone.
I'm running ICS right now (yep, ICS where everything I like just works) and I just checked.
I have 360 apps installed, over a hundred are mine. To see what an app is about, the obligatory equation:
Android = embedded Linux OS + Dalvik Virtural Machine + apps that run in the Dalvik and call Linux services
About 240 included apps in /system/app -> 350 MB
My apps (includes some updates to included apps) in /data/app -> 477 MB
Dalvik runs with a cache, like a browser, so /data/dalvik-cache -> 340 MB
And basic data for those apps, /data/data -> 1,103 MB aka 1.1 GB
My total /data allocation -> 2.1 GB
Used -> 1.9 GB
Free -> 222 MB
And then after all of that comes my internal user storage (the famously so-called internal sdcard in GB and ICS, now just called /storage in Jellybean, but it's still the same thing) -> 9.9 GB
My camera knows to put pictures in that 9.9 GB slot (even lets me point to my actual sd card instead) - but its config data lives in /data/data.
My book reader knows how to send its books to that 9.9 GB area but it's oblivious to the fact that I have an sd card (unless I manage books there by hand with my file explorer) and its config data also lives in /data/data.
But I have more apps than I can name that simply believes that all that exists is /data/data and as I mentioned earlier, plenty of others that simply can't fathom that I might actually have two sdcard-like user storage partitions.
That all adds up to exactly why I want to try a fixed 64 GB model without an sd card at all, if I can get away with it. I reserve the right to change my mind, lol, but I wouldn't mind giving one a spin. It's a convenient solution to the problem.
Legacy apps and legacy app practices are not going to change. Lack of foresight by app developers is not going to change.
Google keeps "helping" us:
We get to use MTP to access storage. How a Windows protocol made its way into a basic Linux operating system still escapes and baffles me, but that's what we got.
They're hiding storage allocation facts by saying that you have places for Pictures, Music and so forth when you look at your storage in Jellybean. On the surface, that all sounds very user friendly. The reality of our thousands of support threads with people trying to figure out where the heck their stuff is so that they can get to it tells me it's not as friendly as Google believes.
As long as we have fixed filesystem allocations, it's going to continue to be a problem.
Android's use of FUSE - a way of creating virtual filesystems on top of the actual ones - together with large-storage devices - is a huge step in the right direction.
But I have 1.1 GB of app data in /data/data and an sd card with a slow interface that is formatted with a Windows scheme as stunning examples of what forced us into today's climate.
Old phones with sd cards and small storage could always operate without the sd card - and - you could interchange sd cards and the phone would still work. Those are the key points of how we got here. And those were good features. But that's why apps to sd is defective by design.