I am currently working on a (commercial) logistics project. We build a (partially) automated storage system in which the goods are stored randomly (think of nano-amazon). The positions of the objects are stored on the main computer and we are at the moment implementing the offsite backup via WAL (any objections?). One of our problems is that we have to operate during a power blackout and we can't produce enough energy for our computers for the worst case duration of the blackout which could be several hours. [This probably will never happen as we are in Germany, but there are some regulations we need to fulfill].
So my idea is to use a tablet [cheaper than a laptop], send the WAL-files to it so that the user can access the data during the blackout. But so far, I have seen no server implementation for tablets (either android or ios). Isn't there any or did I just not find it?
But maybe I'm also moving into the wrong direction. The Database is rather small (<50000 objects in the warehouse with each < 1kb) and the information we need during blackout is just one table (object_id -> position_in_warehouse) so that I even think about writing this information into a file and using git to copy the changes to the tablet. We also only need to know which objects have been removed during the blackout so that this information can easily be migrated back to the original db.
Or do you have other ideas?
Does your time have any value to you? Discard the Android + PostgreSQL option right now.
Keep it simple. You can get a cheap laptop for practically nothing, especially second hand. Since you clearly don't care about it actually working as a backup option, that seems like a no-brainer. You can run a streaming replica with WAL archiving for fallback.
For your real fallback option, you're on the right track with writing out the data you require to a flat file and syncing just that. Remember to actually test it - you should actually use it occasionally and make sure it works.
BTW, for your WAL-streaming backups, I suggest PgBarman, which will manage retention and rotation for you. You should also do logical dumps, and remember to test your backups.
I don't think there's a port of Postgres to Android - to use WAL files you'd need a working server. Even if it was ported, then you can't ship WAL files from x86 server to Android tablet - master and slave have to be the same major version, OS and architecture.
You really should just periodically export your data from Postgres to a simple file (I'd recommend SQLite) and just download it from a server. I suppose your tablets use WiFi and this file would be like 10MB zip-compressed.
Alternatively you could use rsync to keep this file updated. Don't use git - it will keep all previous versions of this file on your tablet - it would grow rather fast.
Related
I am trying to create an Android application which attempts to retrieve deleted/lost data in Android devices. Is there anyway to do this? I prefer to use Flutter, but willing to use any other tech stack. I think, we might need to use low level languages. Can anyone help me out :)
The thing is, we need to access the segment of memory/storage which is not in the directory and not visible in the file explorer. And we plan to use some algorithms to make sense of the data/bits we get and show it to the user
No this is impossible. You can never do it with an Android application.
Accessing the free space with an android kernel is not possible.
You can try to use memory of the phone pretend to be a hard disk and use EaseUS Data Recovery on Windows
After analyzing my Android application with a security tool, it has detected a high level vulnerability "File unsafe delete check". I have investigated about this, and it seems that the problem is that the application uses "file.delete()".
That function is considered unsafe because data could theoretically be retrieved with a tool that scans all the storage device. So, if that way of deleting is "unsafe"... what is the "safe" way to delete files in Android? (to avoid getting that "security error" that is supposedly a "high level" one). What is the proper way to delete files in Android Development?
I am getting the same security warning in 2 different applications, one made with native Java and the other one with Xamarin Forms. Thank you very much!
what is the "safe" way to delete files in Android?
There is none for the vast majority of Android devices. You use delete() on File.
That function is considered unsafe because data could theoretically be retrieved with a tool that scans all the storage device
If the Android device happens to use a classic hard drive (spinning magnetic media), you can overwrite the data before deleting it. On any sort of flash media, that will be ineffective, as the physical location where the data is written can vary with each write operation ("wear leveling").
So, this really boils down to your objective:
If you feel that the user will be harmed if this data is available to be read, store it encrypted with a user-supplied passphrase.
If you are simply trying to avoid this warning, ask the developers of this "security tool" what they are expecting you to do. Or, find a better tool.
This is not an Android specific issue.
It has to do with how file systems work, and the physical storage media it self.
When you delete a file, regardless of API, what is actually deleted is the record in the files table.
The actual data on disk or flash storage remains.
There is a method for secure deletion:
Before deleting the file, overwrite its contents with garbage or zeros several times.
But, this method only works for magnetic media such as hard disks.
Android devices use NAND flash for storage.
Because the number of writes a NAND chip can take before it fails is a lot less than that of magnetic memory, these chips usually come with a mechanism that spreads out the write commands.
What this means is that even if you try to write random data or zeros over your file, there is no guarantee the actual data will be overwritten.
The writes may go to a different sector to avoid wear.
So, on one hand, for flash storage it is enough to overwrite the file once, but on the other hand, it is impossible to do correctly at application level.
If you want to make your application secure, you must make sure to store sensitive data encrypted.
Then, even if someone tries to read the raw storage, they wouldn't be able to recover the data.
Don't store user credentials (like passwords) in regular files on Android.
Use Android accounts API and let the OS manage security.
If you still need file storage but want to protect the data, encrypt it in memory and then write to file.
As said by the other answers the first thing to consider under a theoretical point of view is if there is really a need to store any sensitive information in files to be kept on customer side
If this is really the case, encryption is the real way to guarantee proper security. Files would be protected not only against the recovery after deletion but also during their known life on the device
That said, in the case of a vulnerability assessment - i.e. a static analysis of the code - it would not be immediate to detect that you are calling for a deletion [via file.delete()] of encrypted files. Or maybe you are just calling the deletion of files with nothing to hide
In both these cases the found vulnerability would just be a false positive. Which is part of the game because you can guess that it's quite complicated for an automated tool to understand if something really "deserves" protection or not
What you can do to get rid of the vulnerability is adding the logic to empty the files before calling file.delete(). You have a sample here for this purpose. This will solve the vulnerability detection you are experiencing
I want to be able to sync a "master" data set from a desktop machine to several tablets. I cannot guarentee all devices will be available at the point the data changes so I need the tablets to update when the data set is updated.
The data set sits in a folder on the desktop, its just a bunch of PDF files and a few txt files, nothing special.
At one end of the scale I guess I could run a script that just copies the folder over to the tablet, data updated or not via USB mount. Not really the way I want to go, I want something a bit more slick.
I guess i could call ADB from within a desktop JAVA app to push the files across, although this seems like it might be difficult if several devices want to update their local data set at one time.
Finally, I was wondering about something like OpenMobster (https://code.google.com/p/openmobster/) but I am new to this and it seems fairly complicated, is it worth the complication?
Are there any other options I am missing? I plan on using a Linux based Sync PC if that makes any difference at all? The final restriction I want to cover is that none of this can be connected to the Internet so Dropbox etc are non starters. They were my first thought but sadly no go.
Thanks for the help, I know this is fairly general, but I need a push in the right direction to start more research.
Something like this should do the job:
https://play.google.com/store/apps/details?id=org.pcfilesync&hl=en
Maybe this question is better located at superuser.com?
In Android applications, what is the best strategy to generate reports that can be viewed later by user? I'm talking about normal running of the application, not necessarily errors & exceptions.
I've a few options in mind but each one seems to have issues:
Logcat (use a specific tag “MyAppsLog”, provide user a functionality to read all statements logged using that tag)
Note: I believe the primary purpose of Logcat is for providing debugging info for the developer, not for the end user.
Manually open a flat file and append your logging statements to it.
Note: Can go this route if there is no standard mechanism for logging and report generation. Since this is such a standard requirement, I'm hoping not to re-invent the wheel. Also, if the application is re-installed the file can get lost. If written in sdcard/external storage to avoid this possibility, might not be private.
Use a third party tool like ACRA
or android-remote-stacktrace
Note: I think the purpose of these tools is crash-reporting, I don't think they are the best bet for standard report generation.
Many enterprise applications need to have a way to generate reports (normal running of app, not error), that the enterprise-user can view later. I'm hoping the answers here would be useful to more people than just me.
Well how about using an SQLite database, and dumping the log data in a table? Beats the flat file option I think. You can even aggregate dumped data or start queries on it.
Sqlite is heavy and taking lots of memory and process.
Advantages of flat file:
single point of all log info,
easy to manage,
easy to delete (clear cache)
performance (when file size grow up) performance of apps remain same
Anyone can read log file and can know which process is running on
if data is not big/complex, not that much important (if any one read it) then use flat file only.
I'm currently facing a problem where I should store my object structure on the android device.
The usecase: I'm starting a call to an applicationserver (with the great help of AsyncTask), get a well known response (xml-response) from the server, parse the data and transform it finally into my object structure (highly complex class diagram with many associations between the classes). So far it's working, thanks to the great XMLPullParser ;)
I'm wondering where to store (and of course share) the fetched data between my activities... I already know that I can use sqlite, but I do not have an or-mapper (like hibernate in the j2ee environment). I'm also not allowed to store this sensitive data on the device (in sqlite or file system), so my first approach was to store this data in a singleton (which is of cource being held in memory...). But what happens when system is getting on low memory, can android "destroy" the data stored in my singleton? I already read about extending the android.app.Application class... So what is the best way to securely store object data (called from "webservice") on android devices?
BTW: Android development is that cool! We are currently porting a Windows Mobile 6.5 App to Android and iPhone, and my colleague (reponsible for iPhone-dev) is complaining all the time^^
Regarding an OR mapper, I came across OrmLite the other day. It is a general ORM tool for Java, but it also has some special adaptations that makes it work for Android. I haven't had time to test it myself yet, but it looks promising :)
As for storing sensitive data on the phone, you really don't have the option of storing it only in memory (using some kind of singleton as you suggested). As soon as your application goes to the background, it can be killed instantaneously, so you have to persist what data you want to keep in some way. That being said, if you save data to Internal Storage, this will not be available for any other app on the phone (given that the phone is not rooted, because if is rooted this is easy to get around). I do believe that this same goes for data you store using SQLite, but I'm not 100% certain, so I won't guarantee it.
But basically, if you are sure that your app will only run on non-rooted devices, you should be pretty safe saving your data to Internal Storage. And if that isn't good enough, there there is the javax.crypto package, but I've never used that so I can't really say anything about it.