A bit of background first: I'm running CM7 on a rooted LG Optimus One P500, which one would think would make internal memory a non-issue. After all, I can use DarkTremor or move any application to SD by telling Cyanogenmod to just ignore the "don't allow moving to SD" switch. Well, yes... but neither of these approaches works very well for me. Using standard App2SD comes at a price: mounting the SD card takes, almost literally, hours when you have a couple hundred applications installed and after the latest CM update started causing crashes when the number of apps on SD starts approaching 100. DarkTremor doesn't have this issue, but it is a very fragile solution, as are all other applications that rely on moving the points on the filesystem where Android expects to find the internal memory to the SD card. During my brief testing I had the filesystem corrupted and read-only a number of times and frankly that's nothing I want to worry about when it comes to my phone. (Besides, using DarkTremor with TitaniumBackup produced a number of crashes, making it impossible to restore my data). I see the benefits that these applications offer for people who have a couple of apps that they still use regularly, but which are just a tiny bit too big to fit into the internal memory... problem is: that's not me. I tend to collect a huge number of applications that I don't use for weeks, sometimes months, but which I want available (and locatable through the standard launcher) at all times. And I want a simple, stable solution. On PalmOS there used to be application called "PowerRun" which fitted my needs perfectly. It moved all application data to the SD card for a given application, replacing it with a stub which would cause PowerRun to move the application back to RAM (yeah, the internal memory on PalmOS really used to be the RAM), run the application, wait for it to finish, then write any modified files back to SD card and replacing the application with the stub again. It meant a slight increase for loading time, but it was a very stable, zero-maintenance solution. That's basically what I'm looking for on Android. I realize that things would have to work a little differently, but I think the basic concept should carry over nicely (on rooted devices... regular devices won't allow the kind of access needed): 1. Saving and removing the original application would likely be more disruptive on Android than it was on PalmOS (plus, there's more memory available, so it doesn't make sense to just keep a single application around), so the "collector" should not try to act directly on close, but rather timer-based ... like at 5am for every app that wasn't launched within the last 24 hours and isn't currently running. 2. Stubs replacing the application would probably not work the intended way as generating the needed application would probably fail due to the way Android uses signed APKs and cache. Instead the stub should be a separate application that simply mimics the appearance with a copied icon and description text. That would mean that "Recent Applications" would show two entries, but to me that would be acceptable. It would also mean that while the application is present in internal memory, there would be a second application, but since launchers on rooted devices allow for categories, this would seem like a non-issue: The user would simply move the real application to a "temp" group, while placing the stub in the group where he wants the application to show up. 3. The stub would only work for main app launches, not as handler, which would restrict it to games and non-utility applications... fine with me. Does such an application exist?