I'm looking at this page, which explains how to use a database in the local Android project (in Assets), to populate the application standard database (managed by Android, in data/...) like this. In this way all the data in the assets database are readable in the apk freely, right?
This is not a good way to store data if in the database there is personal info or certificates.
What is the best way store big info data in assets db and personal data in res/xml or res/values? Is there a recommended way to store personal data?
APK files in Android are world-readable by default, so storing sensitive data in there is not a good idea. On JellyBean and later, the app can be forward-locked (aka 'app encryption') which will ensure that your private assets cannot be read by other applications. This is done automatically for paid apps.
The best way would be to not store the data in the APK but download it on first install. You can use Google Play expansion files, which require authentication to download or come up with your own solution.
You could store them in some encrypted form and then decrypt them on first run, but then you will have key management issues.
As luck would have it I was reading about this today. The Android Dev guide suggests that you use internal storage for private data as it is inaccessible to other apps or the user. See http://developer.android.com/guide/topics/data/data-storage.html#filesInternal
I hope that helps.
Related
I am creating an Android app for my teachers. It will be a completely offline app containing videos and documents relating to mechanical engineering. It is a data repository app. What is the best way to store these data(around 2-3Gb or may be more) in the app?
You can consider storing the files in cache that way those files wont be seen by user in the file manager and you can access them easily.
File.createTempFile(filename, null, context.cacheDir)
This is how you can store it and then you can store their names or path in Room database.
You can refer to the official documentation for that:
https://developer.android.com/training/data-storage/app-specific#internal
I'm working on a project using android studio and moodle.
One of the objectives of the mission is to get data from moodle into an archive and get that archive into an SD card to access the data into the mobile without internet connexion.
The client wants the data on the SD card, not te be read by anyone.
So I thought of multiple solutions:
Creating a key on the RAR archive
Encrypting the archive
Encrypting each file within the archive (and the archive ?)
But I still don't know how to pass the data to the android safely. And if those solutions which I thought are good because you need to decrypt it with android later. The best would be that it could be done without internet.
I'm not familiar with moodle, but I assume it is a web app? If so, the easiest way to handle the data securely would be:
Download the file from the web app over HTTPS
Use the Android Jetpack security libraries to store the file on the SD card
Here is an article (from the Google Android Security team) that shows how to generate keys and store encrypted files using Jetpack: https://medium.com/androiddevelopers/data-encryption-on-android-with-jetpack-security-e4cb0b2d2a9
It abstracts away a lot of the crypto work for you.
We are building a Meteor app that will be deployed to the app stores and online.
We need to store assets that will be auto-refreshed with Meteor (eg via hot-code-push), including in the app store versions.
The normal approach would be to put the assets into /public directory.
However, this means that the assets are all insecure and can be accessed and downloaded directly by anyone.
How can we make the assets in a Meteor app:
available to our app (in this case they are audio files that the app will play)
refresh when the app code updates, without requiring a new download from the app store
secure, so that only the app can access them, not outside bandits?
Thanks
Using something like S3 or CloudFront with signed URLs or signed cookies will be a lot more robust than rolling your own solution.
That being said, if you want to implement this yourself you could combine the security ideas from this question with my answer to how to serve files.
The answer really depends on how you want to store your files.
I am writing an app that requires the ability to pull data from a cloud database and store the data locally. I'm using SQLite to store the data when i collect it from the cloud DB, but it's knowing what to do with images.
In the cloud database, I have a URL string pointing to the image. So i now need to be able to grab that image and store it somewhere locally so that i can reference in my code (i need to be able to access it with no internet, so needs to be cached or saved somewhere).
I've done a lot of reading on this but there seems to be some contradiction and dispute in terms of the best way to efficiently store images locally and where. I assume i need to store it as a Bitmap image, but where is considered best for this?
Ideally if the app is deleted, the images should also be deleted. I'm targeting Andorid 4.3 and above only if that makes any difference.
Any pointers appreciated. Thanks.
Store them in the applicatoin package path under the files directory: /data/data/com.your.package.name/files. This directory is removed when your app is uninstalled from the device.
You can access this directory by using:
string filesPath = System.Environment.GetFolderPath (System.Environment.SpecialFolder.Personal);
I am having an application with local sqlite database in an Adobe Air application for Android and iOS.
I would like to give the user the ability to backup and restore the local database. Since on iOS you cannot just save a backup file on the file system/SD card, I am thinking of backing it up to dropbox or to some other place.
It would be great of someone could give me some pointers and code sniplets about the best practises for this problem.
Thanks!
Check out the Dropbox Api section. You can use it to save files exactly as you've described in android without too much difficulty. They provide some good resources.