And can you finally answer...
Surely. He knows where is it. The problem was in how to move this file to ASD.
P.s. i'm trying now to check the filecopyasync for the backup file selected by the user via SAF.singledocument
How can you be so sure? I have hundreds of apps on my devices and the very next day I can't remember when I saved which file and where.
1 Like
You can. If it's a backup of all you passwords and all important documents.
Have you ever done a backup of your PC? Do you remember where is it?
The extension is .zip
Yes, dozens of times.
In different places and on countless external data carriers (external hard drives, ...).
But often enough I still can't find what I'm looking for. 
Resuming:
The big not image file (even previously created by your app but copied via SHARING function somewhere by the user) CAN'T be copied in ASD:
- with Filetools extension because It seems that after sharing, the APP is not more the owner of the file (Filetools.FilecopyAssync is giving - open failed: EACCES (Permission denied)"
- with SAF.CopyDocument or SAF. ReadAsByteArray because SAF can't allocate enough memory because of Google limitations.
It seems that the only way is to ask the user to save this file in cloud and then download it to ASD.
Thanks to everybody who was helping!!!!
Why can't the user save to the ASD, this would save a whole lot of trouble ?
Excuse me please vknow360 but looking to the peace of your extension code and your comment, I understand only now that maybe you can adjust not the ReadAsByteArray function that in any case will be limited to the dimension of the available memory (even substituting an integer) but probably you can change the DocumentCopy function from the same extension by reading and saving only parts of the file (piece by piece)?
In this way the limit of file dimension will be simply forgotten. Maybe I can be the sponsor of this change request?
2 Likes
This is a backup file that has to be saved in a user 'secret' place (better on external sd card reader)
???
How do copy of Big not image file to ASD from non ASD directory
is your topic title. This tells me you want to copy a file that is already in an "exposed" directory (why is it "OK" there ?) to a more secure directory. You could save to the private directory, which protects the data from most external apps, unless the device is rooted.
1 Like
For my purposes i need to copy big not image file from SD card reader (that is a NON ASD DIRECTORY and its much morte secure then the smartfone itself and any cloud) and its exactly what i was writing in the topic title.
If the zip file has been modified while using the app, there is no other option but to upload the file to a server and download it when needed (at least not on Android 11+ devices). Unfortunately, these are the new, superfluous restrictions that apply to everyone (affecting users and developers alike).
Thank you Anke, but I'm able to read small zip files (up to 5MB) with SAF.ReadAsByteArray from non ASD directory (file is chosen by the user with a help of SAF.OpenDocument) and save it in ASD without any problem.
It means that SAF is bypassing this security limits. The only problem that I need to read a big file and ReadAsByteArray is not able to allocate memory (because of integer usage).
I guess that this can be solved by using "upgraded" SAF.DocumentCopy that has to use the same mechanism as ReadAsByteArray but reading and saving file block by block (where each block can be less than 5MB).
Yes, I understood that. Hence my hint (upload the file to a server ...).
On Android 11+ you will have no (other) choice...
I'm testing the app on Android 12 and saf.readasbytearray is working perfectly with small files
Nice, and ...?
It means that the choice is already exists on Android 11+ for small files (it's SAF) and the problem is to upgrade SAF for big files
Again, I suggest saving this backup file to the app's private directory, then, if necessary, it can be copied to the ASD for "unzipping and elaboration". If the user wants to save to the cloud, then the file can be sent there too.
Yes, we got that - and ... what is the conclusion ... ?