I use the internal storage (http://developer.android.com/guide/topics/data/data-storage.html#filesInternal) to store some necessary application files, that the user creates.
I suppose that these files are stored forever right? They are removed only when the user uninstalls the application, am I correct?
In case of updating the application (for example from version 1.0 to 1.1) through the Android Market, then what will happen to the files that were stored from the previous version? Are they deleted or not?
Thank you in advance.
In case of updating the application (for example from version 1.0 to 1.1) through the Android Market, the files that were stored from the previous version will be there on the device and if you uninstall the app to get the new version then the files will be deleted.
Good question - the docs actually don't say anything about any of the persistence solutions retaining their data on upgrade. But just as SharedPreferences and Sqlite database, I suppose it would also persist during application upgrade. The best way to be sure is to test it yourself, though.
(I know it may sound rude, as I'm like telling you to "see for yourself". But I won't mind doing it for you if my current machine is set up for android development)
Related
How do I ensure that a file I created with the application stays in the iOS and Android device even if the application is deleted with Flutter?
Is there a way to this?
I used flutter path_provider, I save it in the external storage in the documents folder, but when the application is deleted, the file is deleted.
Let me explain why I want to do this. Since no unique information about the device can be obtained in applications anymore, I want to do this by giving a unique id with the file I have printed in it, such as imei number or mac address.
About using "non-deletable" file
Personally, i don't think creating file that containing your unique id is reliable. On Android, user have many ways to delete your file (which is properly stored in external storage) intentionally or unintentionally.
Propose solution
iOS: using keychain with your defined unique id
Android: ANDROID_ID
But Android is somewhat unreliable itself. it has been reported that it can be null when app first run, or can be changed after factory reset. The higher android version code the more stable it is. So using it at your own risk.
Quick pick up: https://github.com/GigaDroid/flutter_udid
References:
https://stackoverflow.com/a/2785493/4478019
We have a suite of applications that depend on the sharing of a directory/files on external storage.
I've currently opted out of the Android 10 OS changes to scoping (requestLegacyExternalStorage), but this is going away and I've spent many hours trying to find a solution for simply sharing files between applications.
The only solutions that I see offered are:
SAF - which appears to make the user choose through UI. This is completely undesirable.
Use a File Content Provider - the way I understand this, I would have to make the user install an apk with my provider in it before installing any of my applications. Forcing the user to install two apks to run one application is very undesirable. (Yes, they could both be in one apk manifest but who knows which of my suite they will want to install)
Media Store - My understanding is that this also forces the user to pick something he should have no knowledge of - and is really intended for audio, video, image and downloaded directory.
Am I missing a solution for these simple requirements?
Am I missing a solution for these simple requirements?
There is no simple solution. You would basically need to have each app have its own copy of the shared data (to deal with potential uninstalls) and have some sort of synchronization protocol so each app in the suite can inform others about changes to their copy of the data.
Using SAF is the simplest approach for your scenario. Or, move the data off the device into "the cloud".
My understanding is that this also forces the user to pick something he should have no knowledge of
It is the user's device. It is the user's storage. If you put files in a user-visible location on the user's storage, they are the user's files. Your apps are merely one set of tools for working with those files, nothing more.
I have a android application hosted separately(not on Play Store), for updating app i have to download complete apk and then install even for small changes and bug fixes.
Is there any way to implement differential update mechanism in my app similar to Google play Store(Smart Update Mechanism)
If your questions is "is there an API that does this all for me?", then the answer is no.
If however you are asking, "What design do I need to implement to do this?", then in outline you need to:
send info from the client, so that it identifies which version is currently installed
send the delta between the currently installed version and the new down to the client (in whatever format you deem appropriate - you could just use the output of bsdiff for example which is a version of diff that handles binary files)
read the currently installed apk as a simple binary file, and apply the delta to produce a new binary apk file in a temporary location
install the new apk from the temporary location
clean up the temporary location
It's easy to see how this all works smoothly for the Google Play app's case, where the app executing this code is not the app that is being updated. However it can be got to work for updating yourself - after all Google Play also has the need to update itself!
The concept that you need to know is "Delta Update":
https://en.wikipedia.org/wiki/Delta_update
You must calculate the differences between new and old APK files and generate a Patch file in server-side:
https://en.wikipedia.org/wiki/Diff_utility
https://www.w3.org/TR/NOTE-gdiff-19970901
https://www.chromium.org/developers/design-documents/software-updates-courgette
Then download the patch file in Android client and merge it with the old APK to generate the new one.
Install the new APK...
As far as I know, even when you update an app from the Google Play Store, you are downloading a complete APK, even if the update is just to change a single string in your app.
However, I can think of a way (that I have not tried) to update an app differentially. It will be require a server (from which your app will download the new data/update). You will have to write a code in your app that processes the update from the server and replaces the specified resources (values, strings, links, etc) in your app. You won't be able to change the app logic or semantics, but at least the data can be changed.
In conclusion, I think Angry Birds Transformers does something like this (as it keeps telling me it is downloading new data from the servers). But Subway Surfers require you to download a new APK from Play Store in order to get the new resources for every city their tour visits.
I've got an Android app written in Kivy (Python), which stores local files that should survive an app update (adb install -r).
If the files are stored in a subdirectory of the current directory ("data/data/app_name/files"), I see that they are deleted after update.
However after some experiments I could "solve" this by storing the files in the "data/data/app_name/shared_prefs" directory, which seems to be persistent after updates. By the way, I didn't check but maybe the "data/data/app_name/databases" also is.
Is there a cleaner way of doing things ?
I need to test if I can create a new folder not called shared_prefs nor databases under "data/data/app_name", and if it is persistent.
(this seems kind of a hack because those directories have another dedicated purpose, even though my app is not using them for this dedicated purpose right now)
(NB: I don't want to keep the files outside the app private directory)
There is not a simple way (as in a build hook or similar) right now, but it's something we've specifically discussed in the last few days as the current situation has become a direct problem. I'm not sure what the resolution was, but there will probably be a change in python-for-android to fix it fairly soon.
If you want to keep up to date with this, ask on the kivy mailing list or irc. In particular, knapper_tech was making these changes.
There are some things my application needs to do on first start up(first startup after update) . These actions could be described in a .txt file and then when it is the case read the file and do according to it ,or on the other hand (I lean to use this option) a sqlite database could be used to store the information . The apk file would be shipped with an .txt file/prebuild sql db stored in res/raw or res.asset and then copied into proper space and used. This I have figured out how !, though I'm not sure which option of this two would be the fittest ? One thing that is unclear to me is how could sqlite version mismatch affect me, and if it serious enough to take into consideration ? I 'm using Android api level 4 (Android 1.6) and the future application might be used on several different devices , with different api levels.
These actions could be described in a
.txt file and then when it is the case
read the file and do according to it
,or on the other hand (I lean to use
this option) a sqlite database could
be used to store the information .
Or, they could be implemented in Java.
Well the actions that the application
needs to perform on install / after
update , according to the update
version and the pre update version of
the application
Why not just implement this as regular Java code in your app?
Or, as Albert Einstein wrote, in homage to Occam's Razor: "Make everything as simple as possible, but not simpler."