Swap internal/External Insufficient Storage

[alexcool25565]

Hi, i used the mod to swap the internal to external i did all the steps and everything but i still get the insufficient storage message wheni try to update a app on google play. I dont know if did something wrong?? Any help would be appreciated.

 

[Trevor Philips]

Hi, i used the mod to swap the internal to external i did all the steps and everything but i still get the insufficient storage message wheni try to update a app on google play. I dont know if did something wrong?? Any help would be appreciated.

I remember this problem, i think i solved it by deleting the .txt from the script, i don't remember exactly but i do believe that was the fix

 

[alexcool25565]

I remember this problem, i think i solved it by deleting the .txt from the script, i don't remember exactly but i do believe that was the fix

I did that and it still shows the error :/

 

[Trevor Philips]

I did that and it still shows the error :/

Mind telling me the exact steps you did?

 

[alexcool25565]

Mind telling me the exact steps you did?

1) Download Uni-init v1.0.apk

2) Install like a regular apk and open it

3) Click on Activate and allow with super user

4) Click on Verify to make sure init.d is enabled

5) Reboot your device

6) Download any Root Browser you like from the play store

7) Download 11extsd2internalsd and copy it to your sd card

8) Open Root Browser and copy 11extsd2internalsd and paste it /system/etc/init.d folder

9) Hold click 11extsd2internalsd and set permissions and make sure everything is checked as far as Read, Write, and Execute

10) Download Smanager from the google play store and open and allow with root access

11) Go to /system/etc/init.d and click on 11extsd2internalsd

12) Click at the top where it has Su and Boot and hit save and then exit

13) Reboot your device and your all done!


Did all of those but didnt realize until after that i had to change the .txt on it. i redid all the steps again when i did it.

 

[JVene]

See if you can report to us the storage report from Linux, using the df command.

If you can manage to use ADB (Google for a short download, something like install only ADB), get to a shell and type df /data.

If you have a terminal emulator app, you can use that. If you have to uninstall something expendable to get that, it would be informative to have the information from df /data.

The reason is that the application(s) which swap storage, as you're stating, target the /data/media directory, perhaps through /storage/scard0 or /scard. This directory is what the F6 "considers" internal storage. It's also the typical destination for temporaries when downloading.

Except for Google Play. They use /data/data/com.android.providers/downloads/tmp.

Tell us what df /data/data/com.android/providers/downloads tells you.

99% of the time, this directory is not re-mapped when internal/external devices are swapped, meaning that while other sources of downloading may route to the external card with that swap, Google Play downloads may not.

The storage app in Android "Settings" can lie to you. More accurately, it's not a thorough explanation of storage on the device.

If you have a means of directing Google to download to the SD card, like a symbolic link or a mount, then use that.

 

[alexcool25565]

See if you can report to us the storage report from Linux, using the df command.

If you can manage to use ADB (Google for a short download, something like install only ADB), get to a shell and type df /data.

If you have a terminal emulator app, you can use that. If you have to uninstall something expendable to get that, it would be informative to have the information from df /data.

The reason is that the application(s) which swap storage, as you're stating, target the /data/media directory, perhaps through /storage/scard0 or /scard. This directory is what the F6 "considers" internal storage. It's also the typical destination for temporaries when downloading.

Except for Google Play. They use /data/data/com.android.providers/downloads/tmp.

Tell us what df /data/data/com.android/providers/downloads tells you.

99% of the time, this directory is not re-mapped when internal/external devices are swapped, meaning that while other sources of downloading may route to the external card with that swap, Google Play downloads may not.

The storage app in Android "Settings" can lie to you. More accurately, it's not a thorough explanation of storage on the device.

If you have a means of directing Google to download to the SD card, like a symbolic link or a mount, then use that.

https://copy.com/41Dl9AoRI9iQ

this one didn't work said no such file or directory
df /data/data/com.android/providers/downloads

 

[JVene]

https://copy.com/41Dl9AoRI9iQ

this one didn't work said no such file or directory
df /data/data/com.android/providers/downloads

Right, sorry, the second time I typed it I wrote it incorrectly:

df /data/data/com.android.providers/downlaods

 

[alexcool25565]

Right, sorry, the second time I typed it I wrote it incorrectly:

df /data/data/com.android.providers/downlaods

It still says the same thing

 

[DunderMifflin]

All the solutions I see involve factory resets

 

[JVene]

It still says the same thing

alexcool25565, I must apologize. Normally I'm not such a set of twisted fingers, but for some reason typing this has been a mess.

So...I copied this out of the adb shell after getting the command to actually work on the device, and I STILL had to do it 3 times to get it right.

Yikes, getting old sucks!

This will work!

df /data/data/com.android.providers.downloads

Filesystem                 Size         Used         Free    Blksize
/data/data/com.android.providers.downloads      1.27G      597.62M      703.86M       4096

This includes the result I see on the stock arrangement of my device (I have other configurations that show this instead)

Filesystem                 Size         Used         Free    Blksize
/data/data/com.android.providers.downloads        29.04G        6.50G       22.54G       4096

In the first one, the stock configuration is shown.

In the second one, an experimental configuration I'm discussing in a thread on a proposed theory to remap storage of the device.

Notice how the total free space change dramatically.

Now, to continue this investigation of your machine's configuration, try df on this:

Note: Double check my typing, we've already learned I'm not exactly precise sometimes

df /storage/sdcard0
df /data/media
df /sdcard

On the stock device, these 3 directories are routed to the same place. In the "swapped" arrangement you're using, I expect them to be routed to the external SD card instead.

If your /data/data/com.android.providers.downloads is not routed to the same device as /sdcard and /storage/sdcard0, then downloads from other sources might have room while downloads from Google Play would not.

You can temporarily solve the problem with a mount, or for a longer term solution, put the mount into an init.d script, or use a symbolic link.

Something like (and by that I mean this example is an illustration, you'd choose names and locations you prefer, and my typing may be inexact, I'm not testing this on my device as I type it)

mkdir /storage/external_SD/google_downloads

cp -rp /data/data/com.android.providers.downloads/cache /storage/external_SD/google_downloads

mount -o rw,bind /storage/external_SD/google_downloads /data/data/com.android.providers.downloads/cache

In that example I assume a directory called google_downloads is already created on the external card.

The mount is temporary in the sense that it won't stay around after a reboot.

You can make the mount stick by adding it (not the cp or the mkdir commands) to an init.d script.

You could also choose a symlink instead

mkdir /storage/external_SD/google_downloads

cp -rp /data/data/com.android.providers.downloads/cache /storage/external_SD/google_downloads

rm -r /data/data/com.android.providers.downloads/cache

ln -s /storage/external_SD/google_downloads /data/data/com.android.providers.downloads/cache

Mounts are commands issued to the operating system to control the current running state of the system. They're used to mount devices (like CD Roms, SD cards, new hard drives) in Unix/Linux. They don't persist past reboots unless they're added to the startup configuration of the machine.

Links are part of the filesystem. They're "specialized" entries in the directory, and therefore are retained between reboots.

Some applications don't do well with links, but Google Play doesn't have a problem with them for it's download directory.

The mount and link command examples are "manual" adjustments similar to those found in the various solutions you're using, like app2external_sd or link2sd.

If you learn them you can adjust storage more completely on your own as you discover where things are stored.

I couldn't find documentation on the subject of Google Play's temp directory. What I did was to snap an image of the directory while downloading from Google to see where "new" files had just appeared.

 

[alexcool25565]

alexcool25565, I must apologize. Normally I'm not such a set of twisted fingers, but for some reason typing this has been a mess.

So...I copied this out of the adb shell after getting the command to actually work on the device, and I STILL had to do it 3 times to get it right.

Yikes, getting old sucks!

This will work!

df /data/data/com.android.providers.downloads

Filesystem                 Size         Used         Free    Blksize
/data/data/com.android.providers.downloads      1.27G      597.62M      703.86M       4096

This includes the result I see on the stock arrangement of my device (I have other configurations that show this instead)

Filesystem                 Size         Used         Free    Blksize
/data/data/com.android.providers.downloads        29.04G        6.50G       22.54G       4096

In the first one, the stock configuration is shown.

In the second one, an experimental configuration I'm discussing in a thread on a proposed theory to remap storage of the device.

Notice how the total free space change dramatically.

Now, to continue this investigation of your machine's configuration, try df on this:

Note: Double check my typing, we've already learned I'm not exactly precise sometimes

df /storage/sdcard0
df /data/media
df /sdcard

On the stock device, these 3 directories are routed to the same place. In the "swapped" arrangement you're using, I expect them to be routed to the external SD card instead.

If your /data/data/com.android.providers.downloads is not routed to the same device as /sdcard and /storage/sdcard0, then downloads from other sources might have room while downloads from Google Play would not.

You can temporarily solve the problem with a mount, or for a longer term solution, put the mount into an init.d script, or use a symbolic link.

Something like (and by that I mean this example is an illustration, you'd choose names and locations you prefer, and my typing may be inexact, I'm not testing this on my device as I type it)

mkdir /storage/external_SD/google_downloads

cp -rp /data/data/com.android.providers.downloads/cache /storage/external_SD/google_downloads

mount -o rw,bind /storage/external_SD/google_downloads /data/data/com.android.providers.downloads/cache

In that example I assume a directory called google_downloads is already created on the external card.

The mount is temporary in the sense that it won't stay around after a reboot.

You can make the mount stick by adding it (not the cp or the mkdir commands) to an init.d script.

You could also choose a symlink instead

mkdir /storage/external_SD/google_downloads

cp -rp /data/data/com.android.providers.downloads/cache /storage/external_SD/google_downloads

rm -r /data/data/com.android.providers.downloads/cache

ln -s /storage/external_SD/google_downloads /data/data/com.android.providers.downloads/cache

Mounts are commands issued to the operating system to control the current running state of the system. They're used to mount devices (like CD Roms, SD cards, new hard drives) in Unix/Linux. They don't persist past reboots unless they're added to the startup configuration of the machine.

Links are part of the filesystem. They're "specialized" entries in the directory, and therefore are retained between reboots.

Some applications don't do well with links, but Google Play doesn't have a problem with them for it's download directory.

The mount and link command examples are "manual" adjustments similar to those found in the various solutions you're using, like app2external_sd or link2sd.

If you learn them you can adjust storage more completely on your own as you discover where things are stored.

I couldn't find documentation on the subject of Google Play's temp directory. What I did was to snap an image of the directory while downloading from Google to see where "new" files had just appeared.

I got this https://copy.com/Q0wnWyXBgsyX

Now how would i set up the symbolic link for google play to download stuff in to the sd card?

 

[JVene]

I got this https://copy.com/Q0wnWyXBgsyX

Now how would i set up the symbolic link for google play to download stuff in to the sd card?

This report tells me that you have an 8 Gbyte card (or partition) mounted for access through both /sdcard and /storage/sdcard0. These are commonly routed to /data/media, and therefore the internal SD card, on stock devices. This informs me that you have the app2external_sd application, which I think you mentioned.

This means your directory /storage/external_SD is probably mounted to /data/media.

You can confirm this with the mount command (maybe post the result if you need another eye on it). Typing mount with no parameters shows the report. Also, df /storage/external_SD would report the same space as the /data/media shows here.

Ok, to direct Google play you should create a directory on the external card, which in your case is visible through /sdcard or /storage/sdcard0 (they're the same directory ultimately).

mkdir /sdcard/google_downloads

or something to that effect...your preference, as long as it's under /sdcard

to make sure permissions are wide open,

chmod 777 /sdcard/google_download_cache

The directory you want to re-direct (and this time I'm double checking this ) is /data/data/com.android.providers.downloads/cache

There are a few directories under /data/data/com.android.providers.downloads, and the cache directory is the one you need to route.

Just so any existing content remains available (though it's not critically important)....copy it.

cp -rp /data/data/com.android.providers.downloads/cache/* /sdcard/google_download_cache

Adjust the tail of that command to your directory name preference..it's the directory you made earlier.

You've asked about creating a link, and I did that myself in earlier experiments...Google worked fine with this. There are valid reasons to consider a mount...it's an alternate way of doing this.

But first, the symbolic link method:

Now that the content of the cache has been copied, we must remove the cache content on the source (this MAY free up a little space, but we also need the directory gone to create the link there).

Take a careful moment when typing the rm command below, it recursively removes all files from the given directory and all it's subdirectories...get it right.

perhaps a preparatory:

ls -l /data/data/com.android.providers.downloads

helps make sure we're both pointing to the right place...yes, I left of "cache" above compared to below.

rm -r /data/data/com.android.providers.downloads/cache

That rm removes the content of the cache recursively.

Now, finally, create the link - the first directory parameter (/sdcard/google_download_cache) is the name I use as an example, substitute what you chose to creat

ln -s /sdcard/google_download_cache /data/data/com.android.providers.downloads/cache

The link that is create is the last parameter...the link is cache under /data/data/com.android.providers.downloads

now, ls -l /data/data/com.android.providers.downloads

You'll see a few directories listed, and the one entry named cache will be identified as a link to /sdcard/google_download_cache.

Just so we're clear about all of this, there are a few minor consequences.

If the external SD card is removed, this link will point to nowhere. Google Play would suddenly be unable to download anything.

If the directory this link points to is removed, the same thing results.

If you decide to move things around, you can simply rm the link (that is, rm /data/data/com.android.providers.downloads/cache) - then remake the link to some other location.

You could just mkdir to recreate the original cache directory as it was to undo this.

If you remove app2external_SD, this link will again point to no where.

On a stock device (where app2external_sd has NOT routed /sdcard to the external card), the destination for the same example directory I had you create above would then be

/storage/external_SD/google_download_cache

I point this out in case you uninstall app2exernal_sd and want Google to continue working - you'd have to refashion the link to fix that.


Ok, that's about it for the link approach, now about the mount approach. Mounting is typically reserved for more upper level directories and devices, but it can be applied anywhere and has a similar resulting effect as a symbolic link with an important difference.

Some applications explicitly look for and occasionally have problems with symbolic links. If you copy a directory with symbolic links inside it, what is copied is not the CONTENT, but the LINK (basically just a notation that it is LINK). That is usually the correct choice, but not always. If, for example, you expect to back things up, the link approach produces a LINK in the backup archive, but the CONTENT is not backed up, unless you explicitly tell the backup software to descend through symbolic links to get the data instead.

In general use, if an application refers to directory or a file that is a symbolic link, opens it and uses it - doing exactly what you'd expect...it ends up getting the information from where the link directs it. Not ALL applications do that, and backup software is among them. The copy command (cp) is another.

Mounts, however, don't cause this behavior. When you backup from locations with mounts, there is no link - the backup gets CONTENT, just like any normal directory.

The problem with mounts is that they don't stick around after a reboot. They only stay around while the machine is running. Links are written to a directory, and therefore DO stick around between reboots. Mounts are commands to the operating system...nothing is written to a directory, so they have to be written into startup scripts if you need them to be mounted at every boot (this is a typical configuration choice).

For the Google Play directory this has no serious consequence, but now that you know how to create symbolic links you need to be aware of their side effect, and the alternative.

The mount command's use is like this:

mount -o rw,bind /sdcard/google_download_cache /data/data/com.android.providers.downloads/cache

This is a bind mount...the assumption being that your binding the source directory, /sdcard/google_download_cache to the destination directory /data/data/com.android.providers.downloads/cache

Both directories must exist for this to work. To use a mount instead of a link, you begin with the same steps I listed above for the link, but stop at the link (and don't perform the link).

Then, one time only, after you have removed (with rm -r ) the old /data/data/com.android.providers/cache content, you must create the empty directory named cache to receive the mount.

mkdir /data/data/com.android.providers.downloads/cache

The empty directory will stay between reboots, but the mount command only lasts until a reboot.

To use a mount you must install something like Smanager or Universal Init.d and follow their instructions to place the mount command in a shell script that will execute at every boot.

That's simply how mounts are used which must be persistent. They have significant advantages over links, but require initialization scripts.

I point this out because I know the problem you're solving. I had it too....you will eventually run out of space, again and again. You'll probably want to route other locations to targets on the external card, and now you have some information on how to do that. I've been at this for decades. I know how this is.

There's an axiom I learned back in the mid 80's when 60 Mbytes (yes Mbytes not Gbytes) was considered large for a PC. The axiom is...data will tend to occupy all available space.

That has actually gotten worse over time, so you'll need to understand what you can do about it short of a full scale solution.

I've just completed work on a full scale solution which I have working on my LG F6. For me there is not an internal/external debate anymore. The entire /data directory is routed to a 28 Gbyte partition. I have room from hundreds of applications and download space. I'm preparing a means of installing the solution for F6 devices by minimally experienced owners. Unfortunately it wasn't as simple as mounting external space over /data...that is basically the goal, but the obstacles in the way required that I recompiled a small binary file that is part of the Android operating system. /data is too "top level" to be mounted over once Android is running. It has to be done before Android takes over, but after Linux is up.

I have a short thread on the F3 forum pointing to a technical discussion on the subject on the F6, which documents the theory and discusses my experiments leading to a complete solution to the storage problem.

Well, as complete as the size of an external storage device.

That is my caution to you. Some applications just don't like being messed with, and Google is one of them. This cache directory never caused it a problem, but anything above the cache directory caused Google to repeatedly complain, virtually disabling the phone until I disabled Google.

One can only discover through experiment under these conditions (virtually zero documentation regarding our targets).

 

[alexcool25565]

This report tells me that you have an 8 Gbyte card (or partition) mounted for access through both /sdcard and /storage/sdcard0. These are commonly routed to /data/media, and therefore the internal SD card, on stock devices. This informs me that you have the app2external_sd application, which I think you mentioned.

This means your directory /storage/external_SD is probably mounted to /data/media.

You can confirm this with the mount command (maybe post the result if you need another eye on it). Typing mount with no parameters shows the report. Also, df /storage/external_SD would report the same space as the /data/media shows here.

Ok, to direct Google play you should create a directory on the external card, which in your case is visible through /sdcard or /storage/sdcard0 (they're the same directory ultimately).

mkdir /sdcard/google_downloads

or something to that effect...your preference, as long as it's under /sdcard

to make sure permissions are wide open,

chmod 777 /sdcard/google_download_cache

The directory you want to re-direct (and this time I'm double checking this ) is /data/data/com.android.providers.downloads/cache

There are a few directories under /data/data/com.android.providers.downloads, and the cache directory is the one you need to route.

Just so any existing content remains available (though it's not critically important)....copy it.

cp -rp /data/data/com.android.providers.downloads/cache/* /sdcard/google_download_cache

Adjust the tail of that command to your directory name preference..it's the directory you made earlier.

You've asked about creating a link, and I did that myself in earlier experiments...Google worked fine with this. There are valid reasons to consider a mount...it's an alternate way of doing this.

But first, the symbolic link method:

Now that the content of the cache has been copied, we must remove the cache content on the source (this MAY free up a little space, but we also need the directory gone to create the link there).

Take a careful moment when typing the rm command below, it recursively removes all files from the given directory and all it's subdirectories...get it right.

perhaps a preparatory:

ls -l /data/data/com.android.providers.downloads

helps make sure we're both pointing to the right place...yes, I left of "cache" above compared to below.

rm -r /data/data/com.android.providers.downloads/cache

That rm removes the content of the cache recursively.

Now, finally, create the link - the first directory parameter (/sdcard/google_download_cache) is the name I use as an example, substitute what you chose to creat

ln -s /sdcard/google_download_cache /data/data/com.android.providers.downloads/cache

The link that is create is the last parameter...the link is cache under /data/data/com.android.providers.downloads

now, ls -l /data/data/com.android.providers.downloads

You'll see a few directories listed, and the one entry named cache will be identified as a link to /sdcard/google_download_cache.

Just so we're clear about all of this, there are a few minor consequences.

If the external SD card is removed, this link will point to nowhere. Google Play would suddenly be unable to download anything.

If the directory this link points to is removed, the same thing results.

If you decide to move things around, you can simply rm the link (that is, rm /data/data/com.android.providers.downloads/cache) - then remake the link to some other location.

You could just mkdir to recreate the original cache directory as it was to undo this.

If you remove app2external_SD, this link will again point to no where.

On a stock device (where app2external_sd has NOT routed /sdcard to the external card), the destination for the same example directory I had you create above would then be

/storage/external_SD/google_download_cache

I point this out in case you uninstall app2exernal_sd and want Google to continue working - you'd have to refashion the link to fix that.


Ok, that's about it for the link approach, now about the mount approach. Mounting is typically reserved for more upper level directories and devices, but it can be applied anywhere and has a similar resulting effect as a symbolic link with an important difference.

Some applications explicitly look for and occasionally have problems with symbolic links. If you copy a directory with symbolic links inside it, what is copied is not the CONTENT, but the LINK (basically just a notation that it is LINK). That is usually the correct choice, but not always. If, for example, you expect to back things up, the link approach produces a LINK in the backup archive, but the CONTENT is not backed up, unless you explicitly tell the backup software to descend through symbolic links to get the data instead.

In general use, if an application refers to directory or a file that is a symbolic link, opens it and uses it - doing exactly what you'd expect...it ends up getting the information from where the link directs it. Not ALL applications do that, and backup software is among them. The copy command (cp) is another.

Mounts, however, don't cause this behavior. When you backup from locations with mounts, there is no link - the backup gets CONTENT, just like any normal directory.

The problem with mounts is that they don't stick around after a reboot. They only stay around while the machine is running. Links are written to a directory, and therefore DO stick around between reboots. Mounts are commands to the operating system...nothing is written to a directory, so they have to be written into startup scripts if you need them to be mounted at every boot (this is a typical configuration choice).

For the Google Play directory this has no serious consequence, but now that you know how to create symbolic links you need to be aware of their side effect, and the alternative.

The mount command's use is like this:

mount -o rw,bind /sdcard/google_download_cache /data/data/com.android.providers.downloads/cache

This is a bind mount...the assumption being that your binding the source directory, /sdcard/google_download_cache to the destination directory /data/data/com.android.providers.downloads/cache

Both directories must exist for this to work. To use a mount instead of a link, you begin with the same steps I listed above for the link, but stop at the link (and don't perform the link).

Then, one time only, after you have removed (with rm -r ) the old /data/data/com.android.providers/cache content, you must create the empty directory named cache to receive the mount.

mkdir /data/data/com.android.providers.downloads/cache

The empty directory will stay between reboots, but the mount command only lasts until a reboot.

To use a mount you must install something like Smanager or Universal Init.d and follow their instructions to place the mount command in a shell script that will execute at every boot.

That's simply how mounts are used which must be persistent. They have significant advantages over links, but require initialization scripts.

I point this out because I know the problem you're solving. I had it too....you will eventually run out of space, again and again. You'll probably want to route other locations to targets on the external card, and now you have some information on how to do that. I've been at this for decades. I know how this is.

There's an axiom I learned back in the mid 80's when 60 Mbytes (yes Mbytes not Gbytes) was considered large for a PC. The axiom is...data will tend to occupy all available space.

That has actually gotten worse over time, so you'll need to understand what you can do about it short of a full scale solution.

I've just completed work on a full scale solution which I have working on my LG F6. For me there is not an internal/external debate anymore. The entire /data directory is routed to a 28 Gbyte partition. I have room from hundreds of applications and download space. I'm preparing a means of installing the solution for F6 devices by minimally experienced owners. Unfortunately it wasn't as simple as mounting external space over /data...that is basically the goal, but the obstacles in the way required that I recompiled a small binary file that is part of the Android operating system. /data is too "top level" to be mounted over once Android is running. It has to be done before Android takes over, but after Linux is up.

I have a short thread on the F3 forum pointing to a technical discussion on the subject on the F6, which documents the theory and discusses my experiments leading to a complete solution to the storage problem.

Well, as complete as the size of an external storage device.

That is my caution to you. Some applications just don't like being messed with, and Google is one of them. This cache directory never caused it a problem, but anything above the cache directory caused Google to repeatedly complain, virtually disabling the phone until I disabled Google.

One can only discover through experiment under these conditions (virtually zero documentation regarding our targets).

wow that was alot lol.. anyway im new with this phone and i really dont wanna mess it up can you like guide me through redirecting google play to the sd card. Thanks so much

 

[JVene]

Ok, this is actually a repeat of half that post, slightly distilled.

It is for the symbolic link.

For anyone else reading this, it is assumed for this situation that app2external_sd is installed, meaning that /storage/external_SD and /storage/sdcard0 (and thus /sdcard) are SWAPPED.

If this is being done on a phone that does NOT have app2external_sd installed, then those owners should substitute "/storage/external_SD/ for every appearance of "/sdcard/" in these instructions.


You have to be able to use the ADB utility. To do that you have to be sure that debugging is enabled under "developer options" in the "settings" app. This option is grayed out if the cable is connected.

You should also visit "PC Connection" in settings, select the "media" option (the second option).

You also must have rooted the phone.

Then, open a command prompt, change to the directory where you installed ADB, and type:

adb shell

That gives you a prompt with a $ at the end. Then:

su

The prompt then ends with #, indicating you are now the root user, AKA super user.

If you can't get this far, we have to go over how to use ADB, ensure your USB drivers from LG are installed, that debugging is turned on.


Next, these two

mkdir /sdcard/google_downloads
chmod 777 /sdcard/google_download_cache

Then:

cp -rp /data/data/com.android.providers.downloads/cache/* /sdcard/google_download_cache

Then:

cd /data/data/com.android.providers.downloads

and:

rm -r cache

ln -s /sdcard/google_download_cache cache

I adjusted these instructions slightly, specifically the "cd /data/data/......" to make it a little easier to type the commands and be sure you're in the right position for the two that follow.

That creates the symbolic link with Google Play will use as the download destination.

 

[alexcool25565]

Ok, this is actually a repeat of half that post, slightly distilled.

It is for the symbolic link.

For anyone else reading this, it is assumed for this situation that app2external_sd is installed, meaning that /storage/external_SD and /storage/sdcard0 (and thus /sdcard) are SWAPPED.

If this is being done on a phone that does NOT have app2external_sd installed, then those owners should substitute "/storage/external_SD/ for every appearance of "/sdcard/" in these instructions.


You have to be able to use the ADB utility. To do that you have to be sure that debugging is enabled under "developer options" in the "settings" app. This option is grayed out if the cable is connected.

You should also visit "PC Connection" in settings, select the "media" option (the second option).

You also must have rooted the phone.

Then, open a command prompt, change to the directory where you installed ADB, and type:

adb shell

That gives you a prompt with a $ at the end. Then:

su

The prompt then ends with #, indicating you are now the root user, AKA super user.

If you can't get this far, we have to go over how to use ADB, ensure your USB drivers from LG are installed, that debugging is turned on.


Next, these two

mkdir /sdcard/google_downloads
chmod 777 /sdcard/google_download_cache

Then:

cp -rp /data/data/com.android.providers.downloads/cache/* /sdcard/google_download_cache

Then:

cd /data/data/com.android.providers.downloads

and:

rm -r cache

ln -s /sdcard/google_download_cache cache

I adjusted these instructions slightly, specifically the "cd /data/data/......" to make it a little easier to type the commands and be sure you're in the right position for the two that follow.

That creates the symbolic link with Google Play will use as the download destination.

not sure if you typed this one correctly.
chmod 777 /sdcard/google_download_cache

 

[Muilisx]

Not trying to disrespect anyone or their phones but you knew it was only up to 1.2GB of internal space when you bought it, so after the OS, and bloatware, you're probably around 800-900MB of space available to the user which will go VERY VERY FAST. Rooting, and moving everything to the SD card will only help for so long. The F6 seems like a great phone all around from the phone itself to the camera, but internal space is very low, and is very important when it comes to buying a phone so when I saw the space available, I said, no thanks.

 

[JVene]

not sure if you typed this one correctly.
chmod 777 /sdcard/google_download_cache

Actually, this is the one I didn't type correctly

mkdir /sdcard/google_downloads


It SHOULD be

mkdir /sdcard/google_download_cache


to match the remaining instructions.

The name could be anything you want, but google_download_cache will do.

 

[JVene]

Not trying to disrespect anyone or their phones but you knew it was only up to 1.2GB of internal space when you bought it, so after the OS, and bloatware, you're probably around 800-900MB of space available to the user which will go VERY VERY FAST. Rooting, and moving everything to the SD card will only help for so long. The F6 seems like a great phone all around from the phone itself to the camera, but internal space is very low, and is very important when it comes to buying a phone so when I saw the space available, I said, no thanks.

...and I hope you take this response without offense in kind, but I've seen this general post on several "storage" related threads, though I don't recall the identity on those posts.

I'm a software engineer of decades experience. I know this technology extremely well. While your point is reasonable, it's not the entire story.

Virtually every Android device has this problem. It doesn't matter if primary storage is 1.2Gbytes, 3Gbytes, 5Gbytes or 7. Eventually, if the user installs applications of sufficient size, they all fill up.

This problem IS exacerbated on the F6 and similar devices, but every Android device exhibits the problem.

Android has no good solution on the settings page. It should. It is nearly trivial to correct from the AOSP source (which I have for 7 versions of this OS). They've never addressed the issue. That's Google's failure, or the open source developer community, for not providing a solution to this problem.

I have an F6, which has the same storage problem of the F3 and other phones. Yet, on my F6, I have 28 Gbytes of space for applications, temporaries, data, cache...everything.

I applied the same theoretical solution to the Kindle Fire first generation, but put the additional storage on a network drive. The Fire only has a 8 GByte internal SD, but even the other units, including the Samsung Galaxy tablets, don't have a solution to the storage problem once their internal storage is filled. The extenal SD cards are still unused as PRIMARY storage extension.

I've solved that problem for myself. I'm preparing a beta solution for others. Anyone able to use a custom ROM may avail themselves of a solution on their own. The F6 wouldn't have this problem if custom ROM's addressed it. LG could address it, but ultimately it's Google's fault for implementing a standard which perpetuates this problem.

Consumers should expect that adding an SD card expands storage. They shouldn't have to consider what that storage is limited to. It would be like purchasing a larger SD card for a camera only to learn that the manufacturer didn't mean it could store images, only some temporary files - or that it could store pictures, and LOTS of them, but only at limited resolutions.

Now, you may note that this somewhat supports your point.

My point is that the target of the complaint isn't specifically this model phone, but ultimately is the fault of Google.

After I did the reverse engineering, looked through the AOSP source for the operating system, and realized what is really happening, it took me about 30 minutes to experimentally prepare a solution that worked. It subsequently took about 10 days to polish all the details about that solution and begin packaging it into something end users MIGHT be able to install themselves, given certain caveats (rooting among them), but really...Google could have made this a first class end user solution as simple as a selection on the settings page.

That would have solved this problem for all devices, all models (except the Kindle Fire first gen; it has no external SD slot - which hampered it's acceptance, and they responded to the market).

 

[alexcool25565]

Actually, this is the one I didn't type correctly

mkdir /sdcard/google_downloads


It SHOULD be

mkdir /sdcard/google_download_cache


to match the remaining instructions.

The name could be anything you want, but google_download_cache will do.

It worked, then came to this one
cp -rp /data/data/com.android.providers.downloads/cache/* /sdcard/google_download_cache

no such file or directory

 

[Muilisx]

...and I hope you take this response without offense in kind, but I've seen this general post on several "storage" related threads, though I don't recall the identity on those posts.

I'm a software engineer of decades experience. I know this technology extremely well. While your point is reasonable, it's not the entire story.

Virtually every Android device has this problem. It doesn't matter if primary storage is 1.2Gbytes, 3Gbytes, 5Gbytes or 7. Eventually, if the user installs applications of sufficient size, they all fill up.

This problem IS exacerbated on the F6 and similar devices, but every Android device exhibits the problem.

Android has no good solution on the settings page. It should. It is nearly trivial to correct from the AOSP source (which I have for 7 versions of this OS). They've never addressed the issue. That's Google's failure, or the open source developer community, for not providing a solution to this problem.

I have an F6, which has the same storage problem of the F3 and other phones. Yet, on my F6, I have 28 Gbytes of space for applications, temporaries, data, cache...everything.

I applied the same theoretical solution to the Kindle Fire first generation, but put the additional storage on a network drive. The Fire only has a 8 GByte internal SD, but even the other units, including the Samsung Galaxy tablets, don't have a solution to the storage problem once their internal storage is filled. The extenal SD cards are still unused as PRIMARY storage extension.

I've solved that problem for myself. I'm preparing a beta solution for others. Anyone able to use a custom ROM may avail themselves of a solution on their own. The F6 wouldn't have this problem if custom ROM's addressed it. LG could address it, but ultimately it's Google's fault for implementing a standard which perpetuates this problem.

Consumers should expect that adding an SD card expands storage. They shouldn't have to consider what that storage is limited to. It would be like purchasing a larger SD card for a camera only to learn that the manufacturer didn't mean it could store images, only some temporary files - or that it could store pictures, and LOTS of them, but only at limited resolutions.

Now, you may note that this somewhat supports your point.

My point is that the target of the complaint isn't specifically this model phone, but ultimately is the fault of Google.

After I did the reverse engineering, looked through the AOSP source for the operating system, and realized what is really happening, it took me about 30 minutes to experimentally prepare a solution that worked. It subsequently took about 10 days to polish all the details about that solution and begin packaging it into something end users MIGHT be able to install themselves, given certain caveats (rooting among them), but really...Google could have made this a first class end user solution as simple as a selection on the settings page.

That would have solved this problem for all devices, all models (except the Kindle Fire first gen; it has no external SD slot - which hampered it's acceptance, and they responded to the market).

Nicely said

 

[JVene]

It worked, then came to this one
cp -rp /data/data/com.android.providers.downloads/cache/* /sdcard/google_download_cache

no such file or directory

That would probably mean that Google had cleared the cache and nothing was there.

That assumes the destination directory is correct.

Back out just a little and think on this:

You're creating a directory called google_download_cache inside /sdcard.

That means all the commands that direct attention to that directory should be spelled the same (in case either of us typed it incorrectly).

The source directory is (or was) /data/data/com.android.providers.downloads/cache

That's a directory, in the stock phone, called cache under /data/data/com.android.providers.downloads

If cache is empty, then I'd expect the cp command to say something to that effect, and that would be harmless.

You can triple check that it's working as expected with a simple test.

Start by being connected through the adb shell

then:

cd /sdcard/google_download_cache
ls -l

look at what's listed (could be empty).

Now, stay connected to the shell and use Google Play to download something large enough to take a few minutes.

When it gets going, repeat the

ls -l

command.

I expect a tmp directory will be there. If so, cd to it

cd tmp

no slashes

in either case, tmp or not, do:

ls -l

You should see a file ending in .apk, usually something like download.apk (they may number them if there's more than one, and they may download updates without telling you)

If you repeated ls -l every few seconds, the file size should grow as the download proceeds.

That proves it's working as intended.

 

[alexcool25565]

That would probably mean that Google had cleared the cache and nothing was there.

That assumes the destination directory is correct.

Back out just a little and think on this:

You're creating a directory called google_download_cache inside /sdcard.

That means all the commands that direct attention to that directory should be spelled the same (in case either of us typed it incorrectly).

The source directory is (or was) /data/data/com.android.providers.downloads/cache

That's a directory, in the stock phone, called cache under /data/data/com.android.providers.downloads

If cache is empty, then I'd expect the cp command to say something to that effect, and that would be harmless.

You can triple check that it's working as expected with a simple test.

Start by being connected through the adb shell

then:

cd /sdcard/google_download_cache
ls -l

look at what's listed (could be empty).

Now, stay connected to the shell and use Google Play to download something large enough to take a few minutes.

When it gets going, repeat the

ls -l

command.

I expect a tmp directory will be there. If so, cd to it

cd tmp

no slashes

in either case, tmp or not, do:

ls -l

You should see a file ending in .apk, usually something like download.apk (they may number them if there's more than one, and they may download updates without telling you)

If you repeated ls -l every few seconds, the file size should grow as the download proceeds.

That proves it's working as intended.

Ok thanks and now when i entered this ln -s /sdcard/google_download_cache cache
Says sh: syntax error: 'in' unexpected not sure what that means.

 

[JVene]

Ok thanks and now when i entered this ln -s /sdcard/google_download_cache cache
Says sh: syntax error: 'in' unexpected not sure what that means.

ln is the link command.

In the form you quoted the command must be typed while the current directory is /data/data/com.android.providers.downloads

Are you sure you typed ln, not in...ln stands for link, so that's l as in link, n as in nancy.

 

[alexcool25565]

ln is the link command.

In the form you quoted the command must be typed while the current directory is /data/data/com.android.providers.downloads

Are you sure you typed ln, not in...ln stands for link, so that's l as in link, n as in nancy.

opps lol i put a i instead of a l .

so i did it and when entered it it said Cache link failed file exists then the /data/data/com.android.providers.downlods link came up with the # at the end.