I've been messing around with Android, after having read Android Application Development for Dummies, and nothing else (just to illustrate how little I know) I'm trying to create my first useful, but very simple app.
The app should do the following:
prompt me for a password
read a string (persisted somewhere in the memory)
use my password as a key to decrypt the string
parse the string as xml and display the data to me
other than being a coding exercise, this would serve me as a sneaky way of storing sensitive data that's too copious to remember.
I don't want the app to handle input of this data, I want it to come pre-filled with it. (never mind reusability right now) I don't want to hardcode the string in the code though.
I've decided to store the string in a file in the app's internal storage (if this is a bad idea, feel free to suggest something else). I've found plenty of examples on how to work with these files. But they all deal with creating the file at runtime. What I'd like to do is create the file as part of my Eclipse project, and then have it available to the app at runtime.
Is it possible to do this?
What I'd like to do is create the file as part of my Eclipse project,
and then have it available to the app at runtime. Is it possible to do
this?
Yes it's possible, you can create your file in the assets or res/raw directory, then fill its content when the app is running.
However, I'm not sure if this is the best place if you have sensitive information to store in.
Related
I have an old drawing app on Android, which stores drawings (.PNG files) out on a specific folder on external storage. With Scoped Storage in Android 11, I need to find a way to save files, but I can't seem to find a solution that meets my needs. My app has its own gallery UI, like many drawing apps, so that I can control the selection/view UX.
I've tried:
MediaStore: I inserted files with MediaStore. The issue I ran into here is that I couldn't figure out a way to query just the files that my app created. Querying mediastore always returns a bunch of stuff I don't want.
Storage Access Framework. My intuition with this framework, is that I would probably spend a lot of time and potentially regret going down that road. I don't like the idea of not controlling the file selector (gallery). I also don't like relying on intents for a critical part of my app.
MANAGE_EXTERNAL_FILES. Based on the criteria defined by Google, my app wouldn't qualify to use this, though it would be great (since I could keep my old code).
Use internal file storage. I coded this up, and it's really clean, but I hesitate to roll this out, because uninstalling would mean that users lose their documents. Note that i have a Share intent, so users can "export" files one at a time.
What I want:
To write files where they aren't removed when the user uninstalls my app.
To write my files somewhere that the user can back them up one way or another.
Simplicity. I don't want to confuse existing users by changing things drastically.
Am I missing something regarding my options here? Can Mediastore effectively partition my files so that I can show them in the gallery? Does internal storage seem like the best option for me?
Just create your files in the old fashioned way in your apps sub folder in public Documents directory.
No special permissions needed.
I did some testing and, with an Android emulator, outputted a few pathways:
Internal Storage context.getFilesDir() has path /data/data/package_name/files
Private External Storage with context.getExternalFilesDir(null) has path /storage/emulated/0/Android/data/packagename/files/
Public External Storage with Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES) has path /storage/emulated/0/Pictures/
In my app, I've defined an object that has a timestamp string and an array for images (more specifically, paths to those images), and this information is stored in a sqlite database.
But is this a bad idea? Because if someone wanted to move this app to another device, wouldn't the paths change? I'm a little confused as to how files can be moved around, how different devices impact this situation, etc. I am confused as to what the correct approach is for storing image references in the sqlite table. Do you store absolute paths like above? Or do you store a number representing whether the pic is internal/private external/public external and pull that way regardless of device/file structure?
I'm just trying to make sure I don't publish an app that lacks some critical feature simply because I misunderstood something. Like if I start using an app that can take pictures/store them internally, it's all on internal storage, all on this phone. But if I want to start saving pics to an SD card or something else, I have to change where I store the pics and how I reference them. And what if I upgrade my phone? I'd have to somehow carry/transfer all that stuff to a new infrastructure, etc. Or the "cloud", even.
In other words I am just trying to understand all the possible use cases, here, in terms of how Android app data is stored and transferred.
Your questions are a little broad. I will try to answer them in turns:
But is this a bad idea?
Not in itself. The issue here is how are you managing changes and the Android alterations that may occur in the future (as well as the versions you are currently supporting)
Because if someone wanted to move this app to another device, wouldn't the paths change?
Relative paths would never change. They were implemented (I am guessing around API 2~6) to ensure that hard disk management would not be necessary in apps. By getting the Enviroment.getExternalFilesDir(stuffs..) you would garantee a path to the same file, regardless of readl disk allocation.
how files can be moved around, how different devices impact this situation, etc.
Files from Desktops (PC, Mac, Linux, Ubuntu, etc) follow a contracted with Android devices, that simulate the same disk system. This way, a PC can save a file (png, mp3, custom, etc) in a "root folder" that becomes the same root for Enviroment.getExternalFilesDir(stuffs..) BUT data private to your application is never accessible (on non-rooted devices), to the outside system.
Do you store absolute paths like above?
You can. But I believe this goes against the system best-practices. Saving a relative path, then building a File object, in regards to that path is the correct approach. Do note that the File class in Android expects you to know a bit about the file you are refferencing.... either its extension, name regex, physical location, relational location, etc... you need to know at least one of those.
Finally, what I think you asked:
Can the user replicate the same content in different devices?
For this, you must ensure that the user is "know" for instance, using the Play Store account, you can then have a repository, and have devices syncronize with that repository. Or even add a "export" function, that copies files, and imports them somewhere else.
I am new to this. I have the Android SDK installed with Eclipse. I can work with basic activities and layouts.
I am looking to write this Android application that will;
1) Allow users to sign-in using a pre-allocated password.
2) Login and change the password.
3) Every time the user opens the app, he downloads a CSV file from a server to the SD card.
4) The app parses from the file and displays them on several activities and small frames inside the app.
Think of it as an informational application. But, I'd like to add some intelligence on top of it after I get this done.
I have read many articles and topics but none of them give me a specific approach to do this faster. I have very little time for development.
If there's a similar application that you're familiar with, I'd like to take a look at the code.
I want to know exactly (the code) on how the communication between the app and a linux based server on the web needs to be established. Right now, there's only a CSV file (or an EXCEL file - which one's better to parse? How to decide?) there.
Also, when the CSV file is up to date, I wouldn't want it to download the file again. How to prevent it?
As I said, I am new - so please be patient.
Thanks
If you are new to this and want to develop something fast, why do it the hardest way, in java? There are so many easy toolkits out there, e.g. RFO.Basic, you will be amazed how much you can achieve, fast, that way.
(You asked several questions) Easiest to parse? If you don't have Excel installed on your Android device, the CSV is of course easier to parse, needing only text tools. However, if you have a choice of formats, why not use XML? If you have never worked with XML, there is a little learning curve, but there are lots of tutorials on the web. After that, you'll never want to go back to CSV.
Your last question: how to prevent download of unchanged file? Is this about a big file? In that case start with quickly downloading the hash (checksum) of the file, so that the client can decide if the file has changed.
I'm working on an application that it took me about 2 whole month to collect data.
how can I protect my database and files? because of a big size of database, I zipped it (with password) and put it in asset folder. I can unzip it.
2 questions:
where I can extract it that no one can access it even though they have a rooted device ?
after extracting my database from zipfile ,I want to copy it to my application database . is there anyway users can access the database ?
Depends on how smart an attacker you're expecting. If you're expecting the average user, don't worry about it- just put it in your data directory, they'd have to root the phone to see it. From a power user you can encrypt the files. From a determined hacker that won't work- he'll decompile the apk and find the key. You can pass the key from a website, but a good hacker will run it under a debugger and find the key in memory. The best way to secure most of the data would be not to have it in the app but only download what you need via webservice as you need it, but that will cost money and time.
As I know there is no way to hide your files from user sight. they can access your resources sometimes so easy. but you should encrypt your data.
You can use SQLCipher library to protect your data. see http://sqlcipher.net/
Although it has some overhead but you can distribute your data in a safe way.
Hope it can help you
this should be an easy one for whoever published Android Apps before...
Here is my situation:
I'm trying to develop a "city guide" app and I was wondering if my idea of working with .XML files to structure my data (the client provided a .PDF file with pictures, address, tel. no, websites, opening hours of the different destinations) is the best way to go.
I was hoping to be able to write this app as an "interpreter" for this type of .XML and then easily include other cities or destinations in a city by updating that input XML file.
So this is not a technical question, I know how to pull this off, the question is if this is a good way to go? How do you keep an app easily up to date? Would a altered XML trigger a Market wide update notification ?
My research lead me to believe that this is a comfortable way to update a published Android Market app (prior to this inquiry I consulted:
http://developer.android.com/guide/publishing/publishing.html
All helpful hints and suggestions will be greatly appreciated.
Regards,
Veo.
Once I developed such kind of an app that had to contain the whole information in itself. I structured it in SQLite database that I was shipping along with the application. The file was not directly readable (or at least easy to read) from the assets folder, but every time when the file was altered I copied the sqlite file to the application storage and used it as ordinary application database. The cool thing is that this way I did not have to pay for the parsing of xml every time the application ran.
Several notes here:
My database grew too big and I had to split it in files of 1MB, because this is the limit for a file in the asset folder. For more info see here:
The database update mechanism with the database version still worked well.
When you create the database manually you need to take into account that Android expects one system table to exist in it (it is automatically created if the database is created in Android code). Basically see this answer here for more info on that.