I need to know when a file is deleted from an android device, is it possibile? Are there some intents about the request to delete a file from device or SD?
You can register a file observer for files in some locations (though I've heard rumors this may not work for the simulated "external storage" on some recent versions).
But there is no way to "intercept" as in prevent such deletion, short of modifying the installation of android.
If the file is readable to your app, you could presumably make a backup copy ahead of time.
Related
I have a question, because when I install app, I create .csv file and it's the most important file for my app. When I use this app I always check is this file exists. I put this file on storage, but when I uninstall this app, this file wasn't removed. It's still exits. So what can I do to remove this file automatically? Thanks for response.
All you need do is to locate the file and delete it manually.
Some apps are built to startup from where you left off, especially apps that have regular updates.
Its just a backup plan.
If you're sure you don't need it anymore, simply locate and delete it.
We have built an android app that lets users download content from an http endpoint. The downloaded file is stored via Context.getExternalFilesDir(null) if the external drive is writable otherwise we use Context.getFilesDir() to store internally. In either case, we store the absolute path to a database (which could point to an internal or external file path) so we know how and where to find it later.
We've received a number of emails to our tech support saying that after they close and reopen the app that the files are gone. The people emailing with the problem don't have exact steps for reproducing but that has been their experience. No one on our team has been able to reproduce the bug, but it gets reported consistently.
The same people reporting the problem say that they are able to use the files when they download them. The problem is that when they come back to the app later they have to re-download them.
Am I missing something that the framework is maybe doing to delete the files on certain devices/versions?
I think some might jump to the conclusion that it's an external path issue. Meaning it gets saved there, and when they want to access it later the drive isn't mounted any more and therefore the file is "gone". We have a setting the user can check to force downloads to be saved via the internal method (which tech support has them try) Context.getFilesDir() so I don't believe that would be an issue.
I know this is quite vague but I've been getting nowhere now for quite some time. Perhaps some thoughts on storage in general would be helpful. How have you handled storing internal and external files?
I'm creating several .xml files for export.
Using
Environment.getExternalStorageDirectory();
I can export them successfully to the appropriate path I want to.
I can then see the files using DDMS. I can not however see the files on my device using the file explorer. Yes, I turned off debugging and can see all other files and folders.
You do not indicate what device you are seeing this on. If it is running Android 3.0 or higher, then you will need to scan the file. Quoting myself from a blog post:
However, there is a more subtle shift that is important to developers: the MTP contents are not based on the literal contents of external storage. Instead, MTP contents are based on what files have been scanned by MediaScannerConnection. If you write a file to external storage, until and unless that file is scanned by MediaScannerConnection, it will not be visible to users over MTP.
External storage is scanned on a reboot and possibly on a periodic basis. Users can manually force a scan via utilities like SDRescan. However, the best answer is for you to use scanFile() on MediaScannerConnection to update the media database after you close your file. This will make your file immediately available to the user.
So I want to prevent people from copying files out of my app while it is running.
1) Is there an easier way to detect if files are being copied off my device than through checking if the adb daemon is running?
2) Is there an easy way to enumerate all processes running on the Android OS from an app?
I know Android is not a very secure system, but I would at least like to make it difficult for people to copy files off of my app.
EDIT
To clarify my problem, all the files I have stored on the disk are encrypted. My concern is that I need to unencrpyt these files when accessing them in my app. I am trying to prevent someone from stealing these files while the app is running. I already delete the unencrypted files if someone exits out of the app.
Also, I was focused on adb because I was considering trying to delete unencrypted files if connected by usb. However, I know you can still run adb over wifi on a rooted phone. Now that I think about it, you can probably transfer files over by wifi on a rooted phone as well.
Also, obviously not having the files on the device is not an option.
You seem focused on adb, for unknown reasons.
With respect to internal storage, users cannot copy files off of internal storage of a device using adb, unless the device is rooted. And if the device is rooted, they do not need adb to copy files.
With respect to external storage, that is specifically designed to allow any app, or the user, to copy files from it, again without adb.
Hence, trying to detect adb is pointless.
I know Android is not a very secure system, but I would at least like to make it difficult for people to copy files off of my app.
Then don't put the files on the device in the first place.
I'm not sure if you mean that a user would use your application and put his phone on USB mode and proceed to transfer file off your application folder while your application is still running ?
If some files are needed in order for your application to function at runtime, can't your just make them private to your application ? Like illustrated in this article. Or simply don't put files on the device :)
I'm not sure what "copying files out of my app" means (is your app designed to show/provide files, or are you referring to the resources and other files used by your app).
In any case, you're wasting your time. Android is a very open platform and (particularly on rooted devices) people will always find a way to copy data if they want to.
So I'm making this android application, that needs to read data from user-provided CSV files.
The CSV files are more confortably edited on a desktop computer, so I have no editor in the app, which is 'read-only' ; I assume there is a file on the phone's SD card.
Following the Data Storage documentation, I managed to write a dumb version that reads the file from external storage, hard coding the folder location relative to whetever getExternalStorageDirectory returns. So for the moment I have :
private static final String CSV_FILE = "/Android/foo/bar.csv"
...
File f = new File(Environment.getExternalStorageDirectory(), CSV_FILE);
Then I would connect my phone to a PC, create a "foo" folder in the "/Android" folder (that exists on my phone), copy the "bar.csv" file, and everythings goes fine.
Now obviously, this is not acceptable if I want to distribute the application. So I have a few questions :
The natural solution is to softcode the file location, and in any other system I would rely on a built-in "file manager" or something, to let the user browse to the right file.
Surprisingly I could not find such a control, and it seems like there are lots of third-party File Browser app. Does it mean it is not "customary" to ask a user to choose a file on their phone ? Should I write my own 'file browser' ?
Are there conventions about how I should name my "foo" dir ? I've seen apps creating dir with a name that looks like a java package, am I mistaking it with internal storage ?
There is also a getExternalStoragePublicDirectory method that takes a "directory type' constants. In my situation, would it make 'sense' to assume the file is in DIRECTORY_DOWNLOADS ? (or in some subfolder of DIRECTORY_DOWNLOADS ?)
Should I bother about how a lambda user will put a file on their phone ? To me plugging the phone on my PC is simple enough, but is that really easy on all droids ?
Sorry if all of that sounds trivial, just trying to clear my mind before doing something stupid.
Thanks.
Does it mean it is not "customary" to ask a user to choose a file on their phone ?
Correct. Android, like iOS, tries to get away from "files" as much as possible.
Should I write my own 'file browser' ?
There are certainly plenty of third-party applications for file browsing, some of which support ACTION_PICK or similar operations (e.g., OI File Manager). I will be surprised if nobody has written a reusable component for this.
Are there conventions about how I should name my "foo" dir ? I've seen apps creating dir with a name that looks like a java package, am I mistaking it with internal storage ?
No, you are probably seeing the results of getExternalFilesDir(). If you are only supporting API Level 8 or higher, I'd just use that. If you are supporting earlier versions of Android, you might consider finding out the appropriate directory for your app that would be used via getExternalFilesDir() and use that "manually" for older Android versions.
There is also a getExternalStoragePublicDirectory method that takes a "directory type' constants. In my situation, would it make 'sense' to assume the file is in DIRECTORY_DOWNLOADS ? (or in some subfolder of DIRECTORY_DOWNLOADS ?)
That is for downloads -- more accurately, things the user downloaded that they want to hang onto independent of any installed app. It does not sound like this fits your scenario.
Should I bother about how a lambda user will put a file on their phone ?
What is a "lambda user"? To quote the Bard, "but, for mine own part, it was Greek to me" :-)
To me plugging the phone on my PC is simple enough, but is that really easy on all droids ?
It is somewhat more painful on Android 3.x and higher, as Android moves away from USB Mass Storage mode (think USB thumb drives) and to MTP (think MP3 player) for its USB file transfer protocol. While this has overall benefits, it is annoying for OS X and Linux users, as neither have built-in MTP support. Also, it assumes the user has a USB cable handy. Your overall setup also assumes the user has a desktop OS handy.
Nowadays, more developers would probably go the route of creating a Web app rather than a desktop app, and syncing the data to the device over the Internet. This eliminates the need for fussing with cables and does not tie the user to one specific "desktop" machine for data entry. It does, however, require Internet access, which may or may not be suitable for your situation.