As I’ve been following the topic to always see if it has been fixed the command to get the right path to
"externalStorage.makeFolder (" / NewFolder, shouldLookAtRoot) "
I can state what Scott said, his path to the download folder is missing, the same is for me, I need to create a folder in the “general folder” of the android and get her way, which I still can not …
To copy items to the Download folder you can use the ssk plugin , but unfortunately for me it does not solve this problem =/
Hi again.
I don’t own this plugin so I have to guess a little, but the plugin docs show this function is used to get a path right?
local path = externalStorage.getExternalFilesDir( type ) print("Path: ", path )
I’m not clear on what ‘type’ should be. I’ll leave that to you.
However, assuming you can get the above two lines to work and print a full path to the console, then this ssk.files.* code should do the job of copying a file from documents to the path (from above)
-- 1. Build destination path root (downloads folder or whatever) local path = externalStorage.getExternalFilesDir( ????? ) -- 2. Build source path local src = ssk.files.documents.getPath( "hello123.txt" ) print( dst ) -- 3. Build full destination path local dst = path .. "/hello123.txt" -- 4. Copy the file ssk.files.util.cpFile( src, dst )
See here for more on installing and using SSK:
https://roaminggamer.github.io/RGDocs/pages/SSK2/#installing-ssk2
I’m not totally sure about that path. Earlier in this topic Scott H had written
“if you want [to get] a file in the downloads folder you would do externalStorage.getFile(”/Download/test.txt", pathDocs)"
And so I used that path.
On my old phone (with android 5.1), I can see a “Download” folder right under the root (or actually under “Internal Storage”) and that folder has the same files that I see when I use the phone’s “Downloads” app to look for files. I see that by plugging it into my PC and browsing it as a USB device. On my newer phone, I can’t see anything when when I browse the phone as a USB device. Maybe something has changed.
Anyway, I think that path is good for this plugin. On the other hand, I have some confusion about the names Internal Storage and External Storage. I believe the path “/Download/” refers to a folder under the phones’s Internal Storage rather than on any SD card, which might be considered “external storage” and that seems to be consistent with what I see on my old phone. On the third hand, I don’t see the file!
As a side question, do you happen to know about writing to external storage on iPhones? Specifically, assuming I get this worked out on Android, I’m thinking the procedure for the Apple world will be to
Is that the basic idea?
Also, thanks for the info about the ssk plugin. I’ll check that out.
Hello again externalStorage fans,
I can now report that after working on this all day, on and off, it now works. Strangely, the code that now works is the same code I started with this morning.
I did notice that during the day, the externalStorage plugin got updated, but it didn’t observe that the function had worked until this evening. In fact, I saw the first success this evening sometime after an Android system update (7.0 to 8.1) was pushed to my phone. Probably an unrelated event – or maybe they were chasing this bug too. 
Anyway, it has now worked the last 3 times I tried it with 3 different test files.
I’m going to bed now. I’ll look at it some more tomorrow and try it with the actual files I want to use, instead of test files.
Hello again. Here’s some info from my day of experiments with externalStorage plug-in, and externalStorage.copyFile, yesterday.
Path does seem to be important, or at least interesting, in this matter.
The original path I supplied for the destination file (on the Android phone) was:
/Download/hello123.txt
That path did not work yesterday morning but did work yesterday evening. By “work” I mean: “caused the externalStorage plugin to write a test file that could be seen using the Android app called Downloads/Files on Android phone.” One note on this definition is that during my day of testing yesterday (2018-11-09), my Android phone updated itself from 7 to 8.1.0 After the update, the “Downloads” app had been replaced by the “Files” app.
At one point I used the plugin-method externalStorage.getExternalFilesDir(type) as follows: externalStorage.getExternalFilesDir( “Download” ). That returned the following string:
/storage/emulated/0download/hello123.txt
At first, I thought that was an Ah ha moment, but using that path and then using either the externalStorage plug-in or, later in the day, the SSK library, did not “work.” Both caused the following runtime error message which might be of use to someone that knows the Android world:
Attempt to invoke interface method ‘boolean java.nio.channels.WritableByteChannel.isOpen()’ on a null object reference
After the Android update, I saw the first evidence that any of my experiments had caused a test file to be written to the phone. If I believe the file date stamp reported by the new Files application, one of the days earliest attempts, before I wrote to this forum, had worked – I could view the file “hello123.txt”
I had to try it a few more times, backing out different changes and trying different files, but eventually I got the original code to work multiple times. I skipped a few numbers in my file numbering, but I can now see the file hello999.text. When I view it with Chrome, the path shown n the URL edit box is:
content://com.android.providers.downloads.documents/document/raw%3A%2Fstorage%2Femulated%2F0%2FDownload%2Fhello999.txt
BTW %3A is the colon character ( : )
So, one thing I know is that the path to the Download directory that is needed by externalStorage plug-in is not the same as the one reported by Chrome, or even by the externalStorage plug-in itself.
That’s it for now.
Glad you got it sorted out, path is very different for different versions of Android and sometimes different devices
So “externalStorage.getExternalFilesDir( “Download” )” returning the right path now?
>> So “externalStorage.getExternalFilesDir( “Download” )” [is] returning the right path now?
In my experiments, externalStorage.getExternalFilesDir(type) returns a string that is the end of the long path for that file (as eventually shown by Chrome in its URL box). It’s not clear to me how anyone can use the result of getExternalFilesDir.
For my application, all I want is the ability to copy a file to the device’s Download folder. When using the externalStorage.copyFile method, the path of “/Download/” was what I needed to make things work. Apparently Scott’s software expands “/Download/ “ to the longer path. It does that for a phone running Android 8.1 anyway.
For me, that leads to questions like: What version of Android is required for the externalStorage plugin?
Scott’s build instructions have a comment “Android > 6” However, on the phone I was using, Android 7 did not show the file that had been copied. It wasn’t until my phone received an update to Android 8.1 that the phone began showing files copied to “/Download/”
Should Scott now say that the externalStorage plugin requires Android 8.1 or greater, or do we think that’s only true for the phone I was experimenting with, a Motorola G5 plus?
To be more precise, should Scott now say the user must have Android 8.1 or greater to use the copyFile method of the the externalStorage plugin?
I tested on android 6.0 and copyFile seems to be working.
>> I tested on android 6.0
OK, I guess my Motorola G5 was lacking.
What phones do you test with (just so I’ll have more knowledge when my app gets into the field)?
I use a samsung j 3 and blu vivo 5 mini are my main test devices.
Thanks. I’ll see if I can get hold of a Nexus to try.
Hi Scott, I just bought your plugin. Thank you for your hard work.
json.encode( externalStorage.listFiles() --> gives me the list of files
json.encode( externalStorage.listFiles("/Music") --> doesn’t give me anything
The testing device is note9.
Try
json.encode( externalStorage.listFiles(“Music”)
I tried that already, the results are the same.
I also tried:
json.encode( externalStorage.listFiles(externalStorage.music))
Things are still good for me with this plugin, but then I got to thinking…
This plugin will have to be modified to a 64-bit version, correct ?
“We’re working on integrating this build system into Corona Simulator/Native and supporting existing plugins and settings”
https://coronalabs.com/blog/2019/05/28/corona-google-play-apps-and-64-bit/
Still waiting for more details but based on what corona said I believe not
Excellent.
The part about “Simulator/Native” scares me a little bit. Does the slash mean "and or “or?” I guess I better learn more about Corona Native. I’ve been wanting to do that anyway.
Thanks for the update!
When this is done, you will be able to build 64 bit apps with the simulator as well as Native. We will update Corona owned plugins and any dependencies. But third-party plugins will need to be recompiled to be 64 bit compliant. We don’t have the source for those plugins so we can’t do that.
Rob
Thanks Rob.