media.capturePhoto, some android devices will leave public artifacts.

I’ve noticed when using media.capturePhoto, that some artifacts may be left in the Android Gallery app.  Further investigation shows that this is the .thumbnails folder, and I’m guessing this is a device specific issue.  In my testing, this is happening on at least one LG device, but who knows which others.  I haven’t tested on ios, but I doubt there is the same issue.

e.g.

media.capturePhoto( { listener = callback, destination = { filename = fileName, baseDir = system.TemporaryDirectory } });

For my application, this is really bad.  Short of developing native plugins that work around this issue, is there anything I can do about this?

I was under the assumption that sandboxed files would be somewhat isolated.  Is this a bad assumption?

Thanks for any advice!

Edit:
I wonder if it’s caused by me immediately displaying with display.newImageRect.  This might give me an avenue to hack around this issue… I’ll follow up.

Nope, has nothing to do with display.newImageRect.  The thumbnail is added to DCIM automatically by the camera app, or something.

I will try lfs* and os.remove(), but this seems like a bad solution.

@amdolan I am having the same problem … just stumbled over it.

In my case, the unwanted copy of the photos are in /storage/0000-0000/DCIM/Camera

This is a serious problem.

It’s not clear if it’s solvable via “lfs” / “os.remove” … unless you’re willing to say "any photo created within

a second or so of ‘now’ is likely one of these unwanted photos".

(For one thing, *where* would one search with lfs … the entire “/” tree?  Photo location can

vary from Android to Android (or even day-to-day on the same Android, if the user

changes their mind).)

Did you find a solution?

thanks,

Stan

Stan

I didn’t have any luck with “lfs” / “os.remove.”  The problems you’re describing are pretty much the issues I ran into.  Deleting a photo from the photo library when it shouldn’t be there is kind of a crappy hack though.  

Sorry to report back, but I just reviewed the code, and I didn’t find a fix for this, and we moved to another app platform for my teams product. It seems our use case isn’t supported by Corona SDK, although I hope I would be corrected.  Wish I could help more!

I will try lfs* and os.remove(), but this seems like a bad solution.

@amdolan I am having the same problem … just stumbled over it.

In my case, the unwanted copy of the photos are in /storage/0000-0000/DCIM/Camera

This is a serious problem.

It’s not clear if it’s solvable via “lfs” / “os.remove” … unless you’re willing to say "any photo created within

a second or so of ‘now’ is likely one of these unwanted photos".

(For one thing, *where* would one search with lfs … the entire “/” tree?  Photo location can

vary from Android to Android (or even day-to-day on the same Android, if the user

changes their mind).)

Did you find a solution?

thanks,

Stan

Stan

I didn’t have any luck with “lfs” / “os.remove.”  The problems you’re describing are pretty much the issues I ran into.  Deleting a photo from the photo library when it shouldn’t be there is kind of a crappy hack though.  

Sorry to report back, but I just reviewed the code, and I didn’t find a fix for this, and we moved to another app platform for my teams product. It seems our use case isn’t supported by Corona SDK, although I hope I would be corrected.  Wish I could help more!