Well, does this swap the internal and the external? or is it just some kind of another app2sd application..... I want to know how to make my sd card primary storage.
We know, it's the primary goal.
Not just for the F6, but for a wide range of devices.
The goal, both yours and mine, is to mount the directory /data onto another device (SD Card), or at least all of the important directories under /data.
/data is where EVERYTHING you download or install goes on a stock phone. Even what is called internal SD is simply a mount into /data/media on this phone.
On the F6 that partition is about 1.2 GBytes. The internal storage is a device of 4 GBytes, divided into perhaps 30 partitions, some very small, many are likely 'virtual disks' or some such invention.
The one we're all focused on is that 1.2Gbyte partition which mounts as the directory /data. We want to remap that directory onto the external SD card, but there are significant obstacles.
For one, the stock SD cards are formatted in FAT32 (vfat, as Linux calls it). This filesystem doesn't handle all of the user and permission details well enough for Android to accept it as a replacement for /data or one of the important children like /data/apps or /data/data. For another, remapping a phone like the F6 can't be done prior to zygote starting - that's the dalvik virtual machine which everyone knows as Android.
Before zygote starts, the OS is really just linux. If it were not locked, we could just edit the startup script in init.rc (or it's cousins) and thus mount whatever we like before zygote launches. The F6 bootloader is locked, so that's not an option. Our changes evaporate when the phone reboots.
What we do have are pseudo init scripts, managed from something like universal init.d or smanager, which can be used to remap some things, but they can only run AFTER zygote is launched (they're not installed as part of Linux, they're installed as Android/Java applications).
If we remapped /data at that point, we'd drive the phone nuts. By the time these scripts run, zygote is running, Android has already opened and used important configuration files in various directories under /data (typically /data/data), and yanking them out from under Android at that point causes problems.
As you've observed the various approaches available for linking apk and application data directories can work, but it's not a real solution. Even swapping internal/external SD doesn't really do the whole thing. The storage page in Android tells you the space of the SD card is available, but there are still many important directories working in that precious 1.2 GByte partition, and it still fills up.
I'm working on a hack. My son wants two games which are 600Mbyte and 900Mbyte downloads (some GTA 3 or some such thing). I can force fit the install, but like everyone else I want a real solution.
The hack I'm working on would be able to perform the substitution of the important directories under /data. Remapping /data itself might be a bit much, I'm still experimenting, but I may know during the weekend of Jan 18/19th. If my solution works I'll open a thread for discussion on the subject here, but it won't be ready for anyone less than expert in the Android OS. I'm a developer, more focused on application development, but I know Linux/Unix and have sufficient familiarity with the Android implementation of Linux to fashion a solution for my son's F6, and thus present a theory for others here and other forums who might take the ball and fashion a solution for everyone else.
No solution is without some compromise unless the bootloader lock can be defeated. My own solution begins with repartitioning the SD card, either entirely with one non FAT32 partition (ext2 for my experiments), or with a FAT32 of perhaps 4 GBytes and the rest as ext2 or ext4 (those are Linux filesystems). This means only other Linux or Unix machines would be able to read those SD cards.
The hack I'm fashioning for my son's F6 doesn't compromise on the storage solution - that appears to be complete, such that not only does Android report 26Gbytes available (4 reserved for FAT), but so does the Linux df command.
The compromise I've selected involves a slower, odd boot solution. The phone appears to boot twice upon power up or restart. It does NOT lead to boot loop lock, just two boot sessions. Once completed, storage is wide open.
So far early efforts are very promising. I'm about 90% certain at this point it is possible to make a REAL remount of the important directories in /data ( /data/app and /data/data, for example), such that we can genuinely have the space of the SD card as the primary storage, not some phantom which appears in the storage page of Android's settings applet but isn't real. No further management required either. Once done, installs of applications, data, dex files, temporaries - everything - goes to the SD card. No need to "move to phone" or link, application by application, or - as is my case - force fit a 600 Mbyte install into a 1.2Gbyte partition that only has 350Mbytes available after uninstalling half the library.
I hate it when it does that!
