Tasker and SD Cards

[Abdullah Algarni]

When will the app support the new KitKat policy for external cards read/write ?

Thanks ..
Abdullah

[Pent]

When will the app support the new KitKat policy for external cards read/write ?

To be honest, I've had serious difficulty getting an understanding of how all the various storage locations,
permissions and API calls fit together.

I havn't had a device with an SD slot for a while to be able to test it either.

What concrete problems are you having ?

Pent

[Abdullah Algarni]

I was trying to make a task similar to Redirect File Organizer App method  by moving files from internal storage to external storage in a specific time but it shows the message in the attached. I asked a friend of mine and he told me that the developers must update there apps to the new External Storage policy on KitKat.

I forgot that Tasker can do that so I decide to do it in Tasker rather install an app for that. But I was very very disappointed especially I convince a friend of mine to buy Tasker and do more things with it rather than buy one app for one thing.

The app works fine as I heard on custom roms but I don't want to do all this stuff for a single issue.

Thanks for interest.

Abdullah

[Pent]

I was trying to make a task similar to Redirect File Organizer App method  by moving files from internal storage to external storage in a specific time but it shows the message in the attached.

According to the new policy, Tasker will only be able to move files to a specific directory (with it's own package name) on external storage.

I think it's Android/data/net.dinglisch.android.taskerm

The files in that dir will be deleted when Tasker is uninstalled. There's nothing I (or any other developer) can do to change that.

Pent

[Scott Miller]

Wow, this truly is unfortunate. I've heard about this, but your description is the most clear. Obviously it's Google's way to strong arm everyone to use cloud storage and stop using external storage. I've heard about a few cases where workarounds have been achieved, but I think they require root. I've also heard that apps that are included in system are not subject to this requirement. I would guess the price reduction of Google Drive is part of this tactic, as well.

Scott

--
You received this message because you are subscribed to the Google Groups "Tasker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tasker+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/d/optout.

[Abdullah Algarni]

I think it's about security more than using cloud storage. It's only an update from the developer and it will work fine.

[Scott Miller]

Unless there is a good workaround, this will break every file explorer app that exists, along with many others, like Folder Sync. I understand how a security argument can be made, but I doubt that's the ultimate goal in this.

Scott

[hippoma...@gmail.com]

Based on my reading of Google's policy (see below), it looks to me that we are still able to read and write to any location within external storage, as long as the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions are set for our apps running under 4.4 or later.

Here are Google's exact words about this. Have I misunderstood?

Note: Beginning with Android 4.4, the platform no longer requires that your app acquire the WRITE_EXTERNAL_STORAGE or READ_EXTERNAL_STORAGE when you need to access only your app-specific regions of the external storage using the methods above. However, the permissions are required if you want to access the shareable regions of the external storage, provided by getExternalStoragePublicDirectory().

.

[Scott Miller]

Scott

On Mar 15, 2014 10:08 PM, <hippoma...@gmail.com> wrote:
>
>>However, the permissions are required if you want to access the shareable regions of the external storage, provided by getExternalStoragePublicDirectory().

I had seen this also. Is there a definition of shareable regions? From a different source, someone indicated this means media storage, like pictures, music, etc.

I'm hoping that all of this confusion is unfounded, and that in the end, everything will just continue work.

[hippoma...@gmail.com]

I'm running 4.4 on a device that has external storage, and all of the file manager programs that I use give me access to each and every file and directory on my external drive. Therefore, I interpret "sharable regions" to mean the entire drive.

.

 

[Pent]

I think it's about security more than using cloud storage. It's only an update from the developer and it will work fine.

Please tell me, or point me to, exactly what update I need to make. I don't believe that's the case.

Pent

[Pent]

Based on my reading of Google's policy (see below), it looks to me that we are still able to read and write to any location within external storage, as long as the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions are set for our apps running under 4.4 or later.

Tasker has WRITE_EXTERNAL_STORAGE, that doesn't seem to have helped the OP.

Here are Google's exact words about this. Have I misunderstood?

I don't know, the documentation is appalling and there's no overview. To make things worse, some ROMs apply it and some not. And many devices have 'external storage' which is fixed and inside the device.

Pent

[Pent]

I'm hoping that all of this confusion is unfounded, and that in the end, everything will just continue work.

Unfortunately the OP found otherwise.
 

I'm running 4.4 on a device that has external storage, and all of the file manager programs that I use give me access to each and every file and directory on my external drive.

Read access is undisputed, can you write there too. Also depends on which ROM you have and if you're updated to 4.4.2 or not.

Pent

[hippoma...@gmail.com]

On Sunday, March 16, 2014 3:50:59 AM UTC-4, Pent wrote:

Read access is undisputed, can you write there too. Also depends on which ROM you have and if you're updated to 4.4.2 or not.

Yes, I can write as well as read ... to my entire external SD card. I'm using two different 4.4.2 ROM's on two different devices with external storage:

p5110: aokp_p5110_kitkat_unofficial_2014-03-15
apexqtmo: CARBON-KK-UNOFFICIAL-20140310-0102-apexqtmo

Also, the wording of Google's policy seems clear to me: there are more capabilities to write to external storage under 4.4 than before. According to Google's words, prior to 4.4, you needed READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE for read and write access to all parts of the external storage device. Now, under 4.4 and beyond, you only need READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE to read and write to non-app-specific regions of the external storage device.

There's a slight chance that these 3rd-party ROM's are different from stock ROM's regarding external storage access, but I highly doubt it.

.

 

[hippoma...@gmail.com]

PS: on both of my devices, my "external storage" consists of a user-mounted, separately purchased SD card.

.

[hippoma...@gmail.com]

PPS: on both of my devices, I have written a Tasker task to perform the following Copy File action:

from: /mnt/sdcard/Tasker/userbackup.xml
to: /mnt/extSdCard/save (a directory that I manually created)

This task succeeded on both devices, and Use Root is turned off in the action.

Perhaps this is indeed ROM-specific. Or maybe there is a vendor-specific policy as to which regions of external storage are deemed to be "sharable".

.

[hippoma...@gmail.com]

OK. I just got a thought about what might be the problem.

The quote below is from Google's documentation for Environment.getExternalStoragePublicDirectory. Note the text that I highlighted in red.

In other words, if the device has multiple users, each user is only allowed access to his or her isolated external storage area, with no access to the areas available to other users. Could it be that the OP was trying to copy data from one user's area to another's?

On both of my own devices, I do not specify any extra users besides "Owner".

public static File getExternalStoragePublicDirectory (String type)

Added in API level 8

Get a top-level public external storage directory for placing files of a particular type. This is where the user will typically place and manage their own files, so you should be careful about what you put here to ensure you don't erase their files or get in the way of their own organization.

On devices with multiple users (as described by UserManager), each user has their own isolated external storage. Applications only have access to the external storage for the user they're running as.

[hippoma...@gmail.com]

One more thing: see the documentation, below, for the non-argument verson of Environment.getExternalStoragePublicDirectory, and note what I highlighted in red and in purple.

public static File getExternalStorageDirectory ()

Added in API level 1

Return the primary external storage directory. This directory may not currently be accessible if it has been mounted by the user on their computer, has been removed from the device, or some other problem has happened. You can determine its current state with getExternalStorageState().

Note: don't be confused by the word "external" here. This directory can better be thought as media/shared storage. It is a filesystem that can hold a relatively large amount of data and that is shared across all applications (does not enforce permissions). Traditionally this is an SD card, but it may also be implemented as built-in storage in a device that is distinct from the protected internal storage and can be mounted as a filesystem on a computer.

On devices with multiple users (as described by UserManager), each user has their own isolated external storage. Applications only have access to the external storage for the user they're running as.

In devices with multiple "external" storage directories, this directory represents the "primary" external storage that the user will interact with. Access to secondary storage is available through

Applications should not directly use this top-level directory, in order to avoid polluting the user's root namespace. Any files that are private to the application should be placed in a directory returned by Context.getExternalFilesDir, which the system will take care of deleting if the application is uninstalled. Other shared files should be placed in one of the directories returned by getExternalStoragePublicDirectory(String).

Writing to this path requires the WRITE_EXTERNAL_STORAGE permission, and starting in read access requires the READ_EXTERNAL_STORAGE permission, which is automatically granted if you hold the write permission.

Starting in KITKAT, if your application only needs to store internal data, consider using getExternalFilesDir(String) or getExternalCacheDir(), which require no permissions to read or write.

This path may change between platform versions, so applications should only persist relative paths.

[Scott Miller]

I read that a workaround if the user has root is to modify /etc/permissions/platform.xml. There is a section like this:

<permission name="android.permission.READ_EXTERNAL_STORAGE" >

        <group gid="sdcard_rw" />

        <group gid="media_rw" />

</permission>

My understanding is that the sdcard_rw permission has been removed. Adding it back will workaround the problem. I think that's right. Or maybe I have it backwards and it's media_rw that has been removed. Either way, having both is supposed to fix it. Perhaps the custom roms did something like this. The app developers certainly cannot do this.

Scott

[hippoma...@gmail.com]

OK. I figured out OP's problem. We have been on the wrong track when considering permissions, separate users, etc.

The problem is that he used Move File instead of Copy File.  A "move" apparently will not rename a file across filesystems. He needs to do a Copy File followed by a Delete File.

I rewrote my test task to use Move File instead of Copy File, and it failed in the same way as it did for the OP.

If I remember correctly, the winnt-type filesystem used on android sdcards does not support the "move" functionality across mounted volumes.

.

[Abdullah Algarni]

This not good news :'(

[Abdullah Algarni]

As I said before, this is on the developer to his app.

[hippoma...@gmail.com]

On Sunday, March 16, 2014 1:06:29 PM UTC-4, Abdullah Algarni wrote:

This not good news :'(

Agreed, but sadly, that's how ntfs-type filesystems work.

However, there is hope. Given that you are using Tasker to do the Move File, the Tasker folks could easly rewrite the Move File action to do the equivalent of a copy followed by a delete, under the covers, if the move is meant to go from one mounted volume to another.

.

[Abdullah Algarni]

It works fine on custom roms even with KitKat update.

[Abdullah Algarni]

If I know I will be happy to help, but most of the blogs mention 2 ways to fix this: by costume rom OR that developers must update there apps.

[hippoma...@gmail.com]

On Sunday, March 16, 2014 1:13:10 PM UTC-4, Abdullah Algarni wrote:

It works fine on custom roms even with KitKat update.

On both of my custom 4.4.2 ROM's, Tasker's Move File fails in the same way that it does in your case, when the move goes from one sdcard to another.

However, as I mentioned, the Tasker folks could easiy fix this by changing how their Move File command works for cross-volume moves.

For example, every file explorer app that I have will successfully move files between two sdcards. I presume that these apps are written to do the equivalent of a copy followed by a delete, if a cross-volume move is specified.

.

.

[hippoma...@gmail.com]

In the short term, you could get your "move file" functionality in Tasker as follows:

Write a Javascriptlet which does something like this:

Perform a readFile() of the source file into a variable.
Perform a writeFile() of that variable into the destination file.
Then, do a readFile() of the destination into a second variable.
Compare the contents of the second variable with the contents of the first variable.
If these variable contents are the same, this means that the copy succeeded. In that case, do a deleteFile() of the source.

.

[Pent]

The problem is that he used Move File instead of Copy File.  A "move" apparently will not rename a file across filesystems.

Good spot, I was misled by his assumption in the thread title.

Moving accross FS boundaries has always been a problem.

As it says in the action help:

"Note: files cannot be moved from one file system to another e.g. internal memory to SD. A workaround is to Copy and then Delete."

Pent

[Doomsayer]

I found this trying to resolve the issue I'm having with a backup routine I run that uses "copyFile". The routine backed up my Tasker, SMS, GoLauncher data to the extSdCard location.
The task worked flawlessly until the 4.4 KitKat update and I now receive the EACCES (Permission denied) error.

Anyway I found this and thought it may shed some light on the subject if you didn't know already
http://www.androidpolice.com/2014/02/17/external-blues-google-has-brought-big-changes-to-sd-cards-in-kitkat-and-even-samsung-may-be-implementing-them/

This was useful...

Just to sum up, here are the options 3rd-party apps have on KitKat:

• An app without any permissions:
  • Automatic read and write for designated private folders on the primary and secondary storage
• With WRITE_EXTERNAL_STORAGE, they also have:
  • Read and write for any public folder on the primary (built-in) storage
  • Read (not write) for any public folder on the secondary (SD card) storage

and the references on the use of Storage Access Framework under "Perhaps There’s A Plan"

TASKER IS GREAT by the way LOVE IT!!