[G1 Android Development] lbcoder:
EDIT:

In light of the last post by jubeh, this post is edited simply to address his prior concerns directly for the benefit of other people who might read this thread and become confused about the proposal.

That assumption is entirely unfounded. We have NO INTENTION AT ALL to use *ANY PART* of hacker apps2sd.

That this is EXACTLY what I am meaning to do. Change (actually, EXTEND would be a better word) the way that android handles applications.

Again, YES, EXACTLY. This is *PRECISELY* the objective and precisely the kind of structure being planned.

We don't need to worry about reverse engineering applications themselves. And yes, we have even considered protection of "protected" apps -- the requirement is that they be stored with protection equivalent to existing protection (in other words, not required to protect against root users -- this from google engineer JBQ), and this can be accomplished by encrypting them with a KEY stored in /data such that it can't be read by regular users.

Erratic, I presume you use to refer to the possibility of unexpected unmounting, i.e. pull out the card without unmounting. It is very simple to add in the required behavior to handle these events. There would be nothing erratic about a planned unmount -- the unmount interface will be in the foreground, so any running sdcard apps will already be sleeping, which makes it trivial to 1) tell the user which apps are running, 2) ask the user if they want to shut them down (otherwise cancel the unmount), 3) shutdown those apps, 4) proceed to unmount.

** erratic behavior, i.e. unexpectedly missing sdcard --> when the sdcard is detected as missing, just kill -9 all sdcard apps and give an error popup to the user "these apps were running and you just pulled out the sdcard. Shame on you, they're dead and all unsaved data is lost. Don't do that again."

Actually, it is not as limiting as you suspect...

1) widgets sortof-CAN be stored on sdcard. They, like other apps, need to be killed when unmounting. Though I agree that forcing them internal would be better -- i.e., as has been discussed, the installer needs to be extended to be able to install to wherever the user chooses... if (widget) --> internal always. No big deal.

2) services, no problem. Just be sure to kill them when unmounting.

3) application dependencies, i.e. content providers, shared UIDs... this has all been considered and planned for. Again, it is in the thread at android-platform.

EXACTLY!!!! The objective here is to build a solution strong enough to be MERGED WITH AOSP!!! We don't want to put *all* apps external, only those the user CHOOSES to put external (at install time).

Internal app storage will *NEVER* be enough. Applications have historically grown in size similarly to availability of storage space. Whether this is coincidental (i.e., application developers work to make their apps more complex at the same rate as storage developers), or whether this is cause and effect (i.e., application developers use whatever is available to them regardless of what is available) is not clear, but fact is that being limited to internal storage space will NEVER be enough. Case in point; one of my previous phones was a palm treo 650. It had a total of 32MB internal NVM -- to store OS, applications, and data. And it was always pretty much full (1 MB available). It supported apps-to-sdcard (I had a 2GB card), and it worked great -- allowed me to install all the apps I wanted to, the internal storage was quite inadequate. Now we have these devices with 256MB internal -- 8 times the space, but still, its full. Need to install apps onto sdcard.

Note regarding apple phones: Their storage can NOT be extended in this manner as they lack an sdcard slot. Their objective in this regard appears to be to force users of smaller devices to upgrade the device as storage runs out. Also, apple applications tend to be much larger since it is *possible*, i.e., a large program, like TOMTOM will consume 2+GB of internal storage. A very few of these large programs will consume the entire internal storage, even with much larger internal storage. Combine that with the typical MEDIA requirements means that the fixed large internal storage isn't as big as it seems.

The ability to store applications on sdcard allows the use of MULTIPLE sdcards for virtually UNLIMITED storage. For example, you may have 5 16GB sdcards for a total of 80 GB, or a couple of the soon-to-come 32GB cards for an easy 64GB. Thats more than any applephone I've ever heard of.