In know the audience will range from the inexperienced to experts, and while this discussion is intended to include all, be warned: Nothing here is a downloadable solution for novices or casual users, but is a discussion for those of us who know how to unbrick our phones when we experiment with dangerous ideas, understand the Linux command line, the development tools (specifically adb), and know how to partition an SD card through ADB from the linux command line served from the phone without some downloaded app. If that's not you, you may still find this discussion interesting (and hopeful regarding the storage problem), but only try any of this if you know what you're doing. Read this like the notes from an engineer's desk after running some experiments. What I'm posting here is a working theory tested in my F6 (and genymotion) for a grand solution to the typical storage problem. We're all running out of room when there's an empty 32 GByte SD card installed. We all know that the various "link" and swap solutions aren't really doing the trick. You may have even gotten your phone's storage page to claim there's 29Gbytes of free space, but realize after trying to use it that it's not entirely true. Well...this may do the trick, but it's not without a compromise, but one chosen to be outside the area of compromising storage. If we could edit init.rc we could simply alter the boot sequence so the main directory of interest, /data, would no longer mount from mmcblk0p15 (maybe it's 14, I'm not looking at it right now)..but from some other source, like the external SD card (typically mmcblk1p1). mmcblk0 is the base node of the 4 Gbyte internal SD card, and mmcblk0p15 is a 1.2 Gbyte partition on that card, holding the content of the /data directory. Substituting mmcblk0p15 for mmcblk1p1 (or p2, if the external card has two partitions) would provide a genuine primary source from the SD card for /data, providing THE solution to the storage problem. However, the F6's boot loader is locked, so every time the phone boots, init.rc, much of the root directory structure, and anything we might custom configure is restored to "default" conditions. If not for that lock, this could be as simple as doing something like this just one time: cp -rp /data /storage/ext2filesys/data which duplicates /data and all it's contents (pretty much all the applications and their data), including permissions and links. and then during boot: mount -o rw,bind /storage/ext2filesys/data /data Assuming that ext2filesys represents a partition from the external SD card formatted in ext2 filesystem. It would be more like: mount -o rw -t ext2 /dev/block/mmcblk1p2 If we were making a custom ROM and installation on the external card for this sort of thing, but we're not. We're using the bind option to mount a directory over another directory instead, but it's similar. ....and, of course, a few other machinations in detail. However, the fact that we can't edit init.rc (or it's cousins) without cracking the boot loader lock means that we can't perform this mount before zygote is launched. Zygote is name of the process running the Dalvik runtime, it's basically what everyone see's as Android, running as a process inside Linux. Most here are familiar with smanager and/or universal init.d, or something similar. They run scripts "during boot"....but, they run them AFTER zygote is running, because they're Android applications, not Linux scripts. At that point zygote (another name for Android) is already dependent on the content of /data, and in particular some of it's major and minor subdirectories. Google's playstore is key among them, because it's a wimpy, whiny app that will repeatedly complain once /data is swapped out underneath it, making the phone all but unusable. So....the basic novel idea I'm proposing is to kill the zygote. At this point the astute readers probably have an expression of utter disgust. It's a FUGLY proposition, but one that happens to work so far as I can see. The idea is to view Android in two parts. The first part is Linux. It boots up and operates like a stripped down but otherwise standard Linux build. Once it's going, which happens rather quickly, it launches zygote. That's when you see the boot logo. At that point it's already too late to REALLY substitute storage, unless you're willing to view zygote (and thus the Android PORTION of this two piece structure) as individually rebootable - by killing zygote. Init, the grandparent process of the entire Linux implementation here, will restart zygote, probably within 1ms. When it does, it happens AFTER the substitution mount command example above, making /data serve from the external SD card. You can try this without script editing yourself, if you're a bold experimenter. Simply arrange for a duplicate of /data on an ext2 filesystem, mount it (driving Google's apps nuts), then ps | grep zygote, note the pid and then kill zygote. It LOOKS like the phone reboots, but it's only the zygote rebooting (and thus Android) - NOT the entire Linux operating system underneath Android. And zygote will boot as if for the first time, after having reconfigured Linux the way we want. So far I'm observing zero complications and 100% satisfaction on the storage problem with this approach. No app by app fiddling with links, or move to phone - just space. Actual, real space. If you're familiar with fdisk, mkfs.ext2, mkfs.vfat (for a fat32 partition of you want one), the mount command and such, you can probably put the pieces together yourself. Now, making a script that can grep the zygote process from the output of ps, then sed and/or awk that to get the pid to fashion a kill command is an ugly looking bit of code which causes me to reach back 30+ years into my early Unix work, which I've happily let slip from memory, though Google provides. Frankly I'm so much more comfortable with the NDK, and the stand alone toolchains that I'm motivated to write a C/C++ command line utility to do it instead, but maybe I'll try my hand at the script for a bit. The basic plan is this: Upon power up, Android (as zygote) initializes from the default, internal version of /data as mounted from mmcblk0p15 - the stock version of /data, after rooting, equipped with smanager or universal init.d to initiate a script in /system/etc/init.d. That goes through machinations to mount the ext2 partition (they don't automatically mount easily on the F6) - then, calls another script on the ext2 partition to continue. I suggest this so that simply pulling the SD card boots a "standard" configuration based on the stock version of /data. The second script, probably launched as a new thread (using the & at the end of the command, for example), would perform the substitution for /data served out of mmcblk1p1 or p2, then kill zygote to reboot it. An interesting consequence is that, from the Android perspective, you have two operating systems. One on the internal card at mmcblk0p15, and the other on the external card at mmcblk1p2 (or p1 if you choose a single ext2 partition). This means that all applications you install after such a modification will end up in the external partition. If you pull the card and reboot, with the design plan mentioned above, the "stock" or internal version of /data remains...without those applications installed. Or any photos you've taken, or downloads...etc. This essentially abandons that admittedly puny 1.2Gbyte partition that came with phone, relegating it to a boot and self destroy function, simply to launch the version from the external card. Until someone cracks the boot loader lock (before the phone is outdated and replaced, that is), this may be the only way to gain REAL open storage on the external SD card. Anyone up for a ride?