[TIMOB-25585] Android: MediaModule creates temporary files that don't delete on app exit
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2018-02-23T18:04:35.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 7.1.0 |
Components | Android |
Labels | android |
Reporter | Rodrigo Farfán |
Assignee | Yordan Banev |
Created | 2017-11-10T17:40:17.000+0000 |
Updated | 2018-03-02T17:01:55.000+0000 |
Description
*The results:*
Calling Ti.Media.showCamera without overlay and saveToPhotoGallery set to false, fills the appdata directory with orphan pseudo-temporary files.
*The explanation:*
When you use Ti.Media.showCamera without overlay, it calls
launchNativeCamera(cameraOptions);
Then, in launchNativeCamera method, it creates imageFile variable (MediaModule.java line 231)
. All files included in this list will be deleted after execution (see line 860 in TiApplication.java, method dispose).
Ok, this is not very important as later, in MediaModule, in line 805, when processing the onResult event, the temporary file is deleted:
//Create an output file irrespective of whether saveToGallery
//is true or false. If false, we'll delete it later
File imageFile = null;
if (saveToPhotoGallery) {
imageFile = MediaModule.createGalleryImageFile(extension);
} else {
imageFile = MediaModule.createExternalStorageFile(extension, Environment.DIRECTORY_PICTURES, false);
}
Well, in both cases the code ends calling
private static File createExternalStorageFile(String extension, String type, boolean isPublic)
This method creates a temporary file using the following code (MediaModule.java line 630)
file = TiFileHelper.getInstance().getTempFile(appDir, ext, false);
Well, the last argument in getTempFile method is destroyOnExit. TiFileHelper uses this flag to decide wether to include or not the resulting file in an ArrayList
if (!saveToPhotoGallery) {
//Create a file in the internal data directory and delete the original file
try {
File dataFile = TiFileFactory.createDataFile("tia", extension);
copyFile(imageFile, dataFile);
imageFile.delete();
imageFile = dataFile;
} catch(Throwable t) {
if (errorCallback != null) {
KrollDict response = new KrollDict();
response.putCodeAndMessage(UNKNOWN_ERROR, t.getMessage());
errorCallback.callAsync(getKrollObject(), response);
}
return;
}
}
So, the first temporary file created is deleted after have being copied, but then it's never deleted.
You can check your appdata directory from the app and each time a photo is taken, a new "tiaxxxxxxx.jpg" file is created and never deleted. The app data size is always growing up.
Sorry, I accidentally created this issue in AC Project instead of TIMOB. Can any admin move to the correcto project??
Hello, Please provide a full sample testcode that regenerates the issue. Better to provide a sample app as an attachment here. We will test the issue in our environment. Also, provide the SDK and CLI version you are testing on. If we can reproduce the issue we will move the ticket to TIMOB for fixing. Thanks.
Hello [~rfarfan], Just passing a followup here.Are you able to get that sorted out? Let us know if you still experience any issue. We would be happy to assist you. Best Regards! Regards Axway Appcelerator Support
Sorry, didn't have time to post an example. I'm working on it and will post ASAP. I'm experiencing this issue in a real project and had to perform an explicit clean-up process periodically by deleting "tia*.*" files. Regards
Hi everyone, attached is the sample app in which you can see the way tiaXXXX.xxx files last forever. Regards.
Cannot attach .zip file
Sorry, but I cannot (or don't know) how to attach the zip file with Titanium Alloy project that reproduces the issue. I'm adding a dropbox link to the zip file https://www.dropbox.com/s/7wk6cjllq41glgz/AndroidTempPhoto.zip?dl=0 The test project is a simple app that displays 3 buttons: - "Take photo": opens the camera and takes a photo. It, additionally, makes a copy with a name that follows a pattern. - "List Temp Folder": logs (using Ti.API.info) the Ti.Filesystem.applicationDataDirectory files - "Clear Temp Folder": deletes all files in Ti.Filesystem.applicationDataDirectory that starts with "tia" Using this sample app you can see how tiaxxx.xxx remains in Ti.Filesystem.applicationDataDirectory folder. So, each time you take a photo, the data size of the app grows. In an actual app we've had to periodically delete tiaxxx.xxx files to avoid the app to use up to 19 GB (and growing). Given that Titanium.Media.showCamera success function receives a CameraMediaItemType parameter and that this type doesn't include the file path but the photo data itself via a Blob in CameraMediaItemType.media property, this temp files (tiaxxx.xxx) shouldn't remain orphans in Ti.Filesystem.applicationDataDirectory. From my point of view, this should be fixed as the fact of taking a photo and processing it via CameraMediaItemType.media property shouldn't make the app data keep growing up to device's storage limit. Once the blob is created from temporary file, this file should be deleted. Regards
I think that org.appcelerator.titanium.TiApplication should use org.appcelerator.kroll.util.TiTempFileHelper to perform a clean in dispose method.
Reopening to be investigated by Engineering. [~ybanev] [~jquick] Did you maybe see this before?
PR: https://github.com/appcelerator/titanium_mobile/pull/9666
Hi @ypbnv, any progress on this? We're still manually clearing orphan temporary files as al workaround for this issue.
7_1_X: https://github.com/appcelerator/titanium_mobile/pull/9873
Master merged; waiting for 7_1_X.
Test and other information can be found at: Master: https://github.com/appcelerator/titanium_mobile/pull/9666 7_1_X: https://github.com/appcelerator/titanium_mobile/pull/9873
Closing ticket; Verified fix in SDK Version: 7.1.0.v20180228160738 and SDK Version: 7.2.0.v20180301101144.
Thanks for fixing this issue. I just want to add a comment that, at least for us, may be important: existing apps with this issue won't experience this any more, but the existing tiaxxxx.xxx files will persist for ever. Shouldn't be interesting to add this little snippet to the issue so that watchers and future searchers can totally clean their storage?