Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Flashing a new rom should overwrite the hack. To wipe the ext4 partition of the SD card, check the spoiler under Installation in the first post.What should I do if I want to flash a new ROM and I'm currently using the hack?
You are a Beast... !!!!Changes:
Jun 7 - first release.
-partition-NN.zip
Shrinks the fat32 partition of the SD card and creates an ext4 partition in the freed-up space. To use this, rename the zip by replacing "NN" with a positive integer, where the number represents the desired boundary in GiB (=1024*1024*1024, counting from the beginning of the card) between the two partitions. Basically, the zip takes space from the fat32 partition to make the ext4 partition. For example, assume a 32GB (~32,000,000,000) card, which has about 30GiB of space. Suppose the card has a single partition formatted as fat32 taking up 28GiB of space, leaving 2GiB of unallocated space at the end. If we install the zip as DataOnSD-partition-18.zip in recovery, the card should then have an 18GiB fat32 partition (minus some reserved space in the beginning), a 10GiB ext4 partition, and 2GiB of unallocated space. Note that the boundary you specify needs to be within the original fat32 partition.
If you successfully create the ext4 partition with this zip but change your mind about the sizes you want, you can rename this zip to DataOnSD-partition-delete.zip and install it. Doing this will destroy the ext4 partition and put that space back into the fat32 partition. So in the example above, you'd get back 28GiB of fat32 and 2GiB of unallocated space. Then rename the zip to the desired value and install.
Some notes:
- BACK UP YOUR DATA FIRST! Before making changes to your SD card, back up the data and files on it to some place else. There is always a risk of data loss whenever you change something.
- With TWRP, it's possible to install the zip directly from the SD card. CWM doesn't let you modify the partition when you install the zip from it. So with CWM, copy the zip to the internal storage and install from there.
- TWRP has a built-in file manager you can use to rename or copy the zip. CWM does not. Either way, you can download and use Aroma File Manager if you like. The internal storage used for installable zips is mounted at /emmc and the fat32 partition of the SD is mounted at /sdcard.
- If the card is not partitioned as one big fat32 partition, you can use Android's built-in erase SD function to do so before entering recovery. Or use a PC.
- I made this for your convenience. It's likely too simplistic to deal with potential problems. If you have the knowledge and the right tools to properly set up and format partitions, please use them instead.
As far as I know, Link2SD puts app binaries and app data on the SD card. Most system data files still reside in internal storage. For my hack, all of /data (which is all user and system persistent data) is stored on the SD card. The main implication in terms of speed is that my hack requires a card with fast enough random-access read/write speed so that normal OS operations wouldn't lag. Random-access speed is less of a concern for Link2SD.I'm just curious about the possible difference (speed and so on) between:
1. Repartition of system, internal and cache.
2. Internal to sd.
3. Link2sd.
For my hack, the internal storage is hidden by design. My intention is to keep the internal /data partition separate and independent. That way the phone can still boot up and function if the SD has an error or is missing. If you want to expose the internal storage space, you can simply mount it at another location.I'm on ms323 with repartitioned system, so my internal is 2.56 GB, so I also wonder if (and why) the built in internal will still be there but not usable when on "internal to SD"? If I want to implement "internal to SD", is there any way I can make my built in internal usable, or will it be wasted?
As far as I know, Link2SD puts app binaries and app data on the SD card. Most system data files still reside in internal storage. For my hack, all of /data (which is all user and system persistent data) is stored on the SD card. The main implication in terms of speed is that my hack requires a card with fast enough random-access read/write speed so that normal OS operations wouldn't lag. Random-access speed is less of a concern for Link2SD.
For my hack, the internal storage is hidden by design. My intention is to keep the internal /data partition separate and independent. That way the phone can still boot up and function if the SD has an error or is missing. If you want to expose the internal storage space, you can simply mount it at another location.
If you want to take it further, there's a way to use the internal space and the SD space more transparently. Under Linux, on which Android is based, you can use something called LVM to make both internal and external space appear as one volume. The risk is that if the SD card becomes inaccessible, you'll have a big problem. So I'm going to assume this is not what you're asking.
Hope this helps.
Yeah, as far as I know, Samsung SD cards have the best random access performance, so they do well in smart phone applications. There are lots of counterfeits though. So check the card is genuine with SD Insight and/or a random I/O benchmark test.Well, I have a Samsung 32gb class 10, and if I'm not wrong, it has a good random a, r/w. I'm quite sure that some apps like chrome and fb, slows down a bit when I link their odex/dalvik with Link2sd, maybe I'm wrong?
My system is 572mb right now, so I guess it would be smart to expand that size before your hack or is it smarter to have a big internal for those hidden data files? What's your advice?
Yeah, as far as I know, Samsung SD cards have the best random access performance, so they do well in smart phone applications. There are lots of counterfeits though. So check the card is genuine with SD Insight and/or a random I/O benchmark test.
One thing that might cause a slowdown is when most memory cells on the card have been used, each write operation now incurs an extra erasure or a copy+erasure step (as SD cards don't support trim commands, as far as I know). Browsers and social networking apps read/write a lot of small files, so the impact on their performance is greater. If this is the case, you can try to erase all memory cells with SD Formatter. If you know how, you can also use F2FS instead of Ext4. F2FS should be more efficient on an SD than ext4. Another tip is to mount the partition with the "noatime" flag. Also, make sure your partitions aren't misaligned.
As for how you choose to solve the storage problem, I can't give you general advice. Each person's requirement or preference is different. Linux (and by extension, Android) is quite flexible, so there are several different solutions. If you really care, learn how each solution deals with the problem and use the one that applies to your situation.
If you're looking to implement your own solution, I might be able to give you some technical help. If you're looking for user experiences, you should ask other people's opinions because I've really only used my own solutions and I'm clearly biased.Good luck.
So is there any easy way to partition f2fs, mount noatime flag, align and all? Any tools, scripts? I assume gparted does the trick with f2fs...
Do you notice sluggishness with browsers and fb with the hack? Dalvik cache is on the SD with the hack, so my guess is you would experience the same slowdown with your SD card as you've mentioned before when linking dalvik with Link2SD.I installed your internal2sd and it works flawlessly so far. I'm pretty sure I'm not going to use this phone forever so if there's no easy (flashable zips/scripts) way to change nand to f2fs and a ROM with that file system, I'm ok with what I've got. Just to make sure I understand - to use the f2fs on the sd partition, do I need my nand to be the same or? If not, is it possible to edit your zip to f2fs (including format to f2fs)?
Do you notice sluggishness with browsers and fb with the hack? Dalvik cache is on the SD with the hack, so my guess is you would experience the same slowdown with your SD card as you've mentioned before when linking dalvik with Link2SD.
You can use f2fs for the SD partition while leaving your internal volume as ext4. That's what I've done with my F6. There are two parts to doing this. Just like my hack, there's a "copy" part, and there's an "install" part. The copying part can be done on a Linux PC, since the SD card is removable from the phone, unlike internal memory. It can be done in recovery, if the recovery has support for f2fs already. To see what file systems are supported, you can use command "cat /proc/filesystems" in recovery. I don't keep up with development of various recoveries, so I am not sure which recoveries or which versions have support.
The installation part requires a replacement binary that supports mounting of f2fs volumes. I have that. The other thing is rom support. If your rom's kernel already supports f2fs, then it's straightforward. I think newer CM versions have added f2fs support, but since the kernel is built individually for each device, I don't know whether f2fs-enabled kernels have become universal for custom roms. If your rom's kernel doesn't support f2fs natively, it's possible to build a kernel module. Like I've mentioned, I've done that for the F6's stock kernel. Since LG's released kernel source is easily compilable, it's not technically difficult to do this for other devices, but it does take some work.
If you're really interested in this, check /proc/filesystems for both the rom and the recovery. I can even give further instructions if you're determined but your device doesn't have native support. I think most people who want to do this do it for performance. Using this on the SD in the manner I've done goes through a couple of additional layers (kernel module, SD interface), so I can't say the performance benefit is definitely there. I should also mention that f2fs itself is still very much work in progress and might not be completely reliable yet. The reason I choose to do this and use this is more for longevity of the SD card. Just want to say I'm not recommending it or advising against it, but if you decide on your own that you want to experiment with it, I can provide some help if you need it.
So the hack is working with cm12.1? Are you using the binary version or the initd version? Do you know if selinux is enabled for your rom?Hehe, I played around with your hack and messed it upShould probably have read through the thread more before I started deleting apps manually - apk, dalvik and data, but it kept coming back after reboot? So I also used the file manager in twrp to delete the same files and was hoping it would work, but after that the whole partition was wiped, hehe?
I've had some problems uninstalling apps (cm12.1) that wasn't downloaded from the play store.
Restored my ROM and back to zero
The f2fs thing is something that really excites me and I would love to implement it in the phone, the ROM and the card, but one step at the time. The card would be a nice start
I'm using vm03's cm12.1 on my ms323. I tried to format my partition to f2fs on my card with gparted on Ubuntu, but there was a "damaged GPT partition" error? Will try to sort that out first if it's not possible via twrp
Thanks for all your effort![]()
Xperion never took that long to boot for me. It was always around a minute or less for every ROM.Somehow my boot time, with SD hack installed as init.d, decreased by >10x when I upgraded from Xperion ROM (~8 minutes @ loading screen) to the Carbon KK ROM (~45s). Same installation method and both clean wipes. I initially thought SD hack's tradeoff is more storage for substantially increased boot time. It was a pleasant surprise to see I was wrong.
I'm curious why there was such a drastic difference in the boot times between the two ROMs. Any idea why?
Xperion never took that long to boot for me. It was always around a minute or less for every ROM.
After I installed the SD hack, phone took ~8 minutes to boot, but afterwards phone works as normal.
It might have been due to Android doing a full scan of the SD card when booting. Not certain, but I thought it was similar to my tablet, with built in SD, which can't be accessed until after the boot scan.
That's a long boot time. Many people have used the hack with Xperion, but so far no one has reported seeing such a long boot time. Perhaps some processes deadlocked and then timed out? Maybe some process was in the middle of a blocking I/O call when the new partition was being mounted? Not sure. To debug, you could try to use ADB to check which process does not finish loading in time. If you're using the init.d version, you could try the binary version (-install.zip) to see whether the behavior is different.I'm curious why there was such a drastic difference in the boot times between the two ROMs. Any idea why?
So the hack is working with cm12.1? Are you using the binary version or the initd version? Do you know if selinux is enabled for your rom?
In twrp, the /data volume in emmc is accessible at /data (if mounted). The replacement /data volume on the SD is located at /sd-ext (mount it first). The /system volume where system apps are stored is at /system. You probably know all this. So make sure you delete the right files. Also, check my -dalvik.zip if you wipe dalvik cache.
Not sure about the gpt error. Since you have ubuntu, there are two ways to do the copying. One way is to partition and format the volume as f2fs on the PC, and then use twrp to copy files. This requires the f2fs volume to be supported and mountable by twrp. If you want to do this, let me know and I can modify my -copy.zip for you or tell you how to modify it. The other way is to partition and format as ext4 and do -copy.zip as you normally would. Then use ubuntu to do the conversion to f2fs. This is how I did mine since the twrp version we have for the f6 does not support f2fs.
No, if the hack is active, new apps get installed to the SD card and are run from the SD. The internal storage is left untouched. If copies were to be stored in the phone's internal flash memory, then at some point the internal space would be full and it would no longer be able to hold a copy of any new app. It doesn't make sense to me that a hack meant to expand storage would still be limited by the internal space.When I install a new app, does it copy automatically to the hidden internal?
Is there any risk that the hidden internal gets full, or is it limited to system data?
If you're doing a dirty flash, you just need to wipe cache, wipe dalvik, flash rom, and apply -install.zip and -wipe-dalvik.zip (to fix the dalvik folder). For a clean flash, you should wipe data/factory-reset, flash, boot to rom, set up, go back to recovery, wipe external partition (see 1st post about using "rm -rf" to wipe rather than formatting), install -copy.zip, and install -install.zip... basically go though the steps as if you're starting from scratch.When updating my cm12.1 I know I need to install your hack again, but can I leave the internal unwiped, (will new files add automatically), or is it nessesary to wipe and copy > install your hack every time?
However, I am now running into a few apps saying my phone is not supported. CVS for one. Handcent won't show in the market.