• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

SD hack for storage expansion

FYI.. Everytime a switch. Through. Roms all i have to do its flash the copy to sd zip and the install sd zip cause the ext4 on my sdcard its still intact but. Its only on the kk of course i always do a backup of each rom depending if its 4.4.2 or 4.4.4 that means that the stock JB would not work
 
I just wanted to say thanks to all those involved/helping with this. Fantastic to see this kinda of thing still being worked on. I've not got it setup on my phone yet, but I plan to shortly, so hope it all goes smoothly.
 
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.
 

Attachments

Last edited:
My dearest master developers :)

I'm just curious about the possible difference (speed and so on) between:

1. Repartition of system, internal and cache.

2. Internal to sd.

And

3. Link2sd.

???

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?

Please, some good advice would be appreciated, thank you :)
 
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.
You are a Beast... !!!! :cool:
 
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.
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 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?
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.
 
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.

Very helpful thanks :)

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?

Thanks a lot :)
 
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.
 
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.

Very interesting, thank you :)
It's amazing how it's possible to learn new things all the time :)
I've been using fairly cheap smartphones since the first htc Desire arrived: rooting, repartitioned, tweaked and bricked, hehe. But I'm still a noob, mostly listening to professional advices and guidance, while not necessarily understanding everything :)

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...

Thank you again :)
 
Last edited:
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...

Partition alignment is easy. Most modern software should do that. To check manually, (with BusyBox installed or inside recovery) use command "fdisk -lu /dev/block/mmcblk1". The starting sector of each partition should be divisible by 2048 (for aligning to MiB/MB since 1 sector=512 bytes). If you know the erase block size of your SD card, you can even align to erase block boundaries. I'm not sure about your phone, but for the F6, if you check how the internal flash memory is partitioned, you can see most of the partitioned (not all because some are small) are properly aligned to the erase block size (as one would expect from LG). So if you repartition your internal flash, it's a good idea to pay attention to partition alignment.

The "noatime" mount flag can be used for any Linux file system, including ext4. It basically tells the kernel to not record file access time. Recording the access time implies writing to disk even when you only intend to read from it. The stock rom mounts its partitions with "relatime," which is a compromise that only triggers updates of access time under a certain condition. For most applications, relatime is probably fine. My thinking is that some apps that store a lot of small temporary files like browsers might benefit from noatime, but I can't say what difference it would make. Anyone who cares about this can run some benchmark tests to decide for himself/herself. To change the mount option, you can use the command "mount -o remount,noatime /data", where /data is the mount point of the partition. To make that permanent, you probably need to do that in some boot script.

As for f2fs, well, that's a bit trickier. That's why I prefaced with "if you know how..." You can find a lot of guides online for people who want to convert their internal ext4 partitions to f2fs. If you're using an external partition on SD for storage, it's not too hard to create an f2fs partition in a Linux environment. The hard part is kernel support. Either your kernel has f2fs support already or you'd need to compile/get an f2fs kernel module for your kernel. I don't know enough about your phone to comment on your situation, but for the F6's MS50012b stock rom, I can provide everything needed to use f2fs.

Sorry if I'm being too technical or too general. If you're a user of my hack, I can be more specific about changing certain things. If you're looking for help to get things working on your own, I can provide some technical info. As for easy-to-use tools, scripts, etc., I can't say much because I usually do things manually and write my own scripts. Feel free to ask questions though if I can help you in this matter.
 
WarrantyVoider, very interesting information, thank you :)

Been googling around a bit as well... Obviously there's a few bits we can do to improve performance and durability that I didn't have a clue about :)
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)?

Thanks bunches for professional support :)
 
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.
 
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.

Hehe, I played around with your hack and messed it up :) Should 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 :)
 
Last edited:
Hehe, I played around with your hack and messed it up :) Should 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 :)
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.
 
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?
 
Last edited:
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.
 
Xperion never took that long to boot for me. It was always around a minute or less for every ROM.

Xperion ROM by itself booted up fast. I was using that for a while until I needed to install the SD hack. After I installed the SD hack, phone took ~8 minutes to boot, but afterwards phone works as normal. It wasn't that big a deal to me since I rarely rebooted my phone. I did avoid Google maps because it sometimes can cause a hard crash, which required hard reboot by pulling the battery.

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.
 
Last edited:
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.
I'm curious why there was such a drastic difference in the boot times between the two ROMs. Any idea why?
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.

If you feel the problem is caused by the hack and I can reproduce the problem on my end, I can check whether there's some kind of conflict.
 
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.

Sorry for late reply, been working and sleeping mostly so didn't have time to do much else really.

Your hack have made my phone even better. I mean, with vm03-cm12.1 (stripped down to 350mb), with Sense 7 Blinkfeed (as an "app" thanks to QuickShortcutMaker), ROM themed to perfection, tweaked with xposed and 7.5gb internal (thanks to your hack) my cheap ms323 is more than perfect :)

I'm using your binary hack btw.

I will dig into the f2fs thing as soon as I have time :)

Just curious:

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?

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?

Thanks :)
 
Last edited:
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?
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.

So with my hack, the internal space used for /data shouldn't get full, because no new data should be stored there once the hack is activated during boot.

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?
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.

If you're asking whether you can dirty-flash when you update, well, that depends. Typically, you could, but that's something you should check with the rom developer in case some old settings cause conflict with a new build.
 
Ok. Not sure if anyone else has run into this issue as of yet. I did everything correctly. As I now have 3GIG of app space. Didn't need tons. I have a 7GIG I split down the middle. 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. It seems almost like my phone is being considered a Tablet. As the Handcent Anywhere shows but not the regular SMS app. Any suggestions? Or do you already have a fix that I missed in the workarounds. Thanks.
 
Do you have another rooted device that you can install these apps on? If so then just install them on your other device and then use a root file manager to navigate to /data/app and then copy them to your SD card and install them manually. There are some large games that the play store won't let you install on the f6 because they are larger than the actual internal storage and I used this method to install them after installing the hack. One example would be need for speed most wanted.
 
Back
Top Bottom