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