There are only few questions # so about Android Auto Backup. I have not used this before so went through the documentation first!
https://developer.android.com/guide/topics/data/autobackup.html#Files
Then I made a sample app and managed to add to the list of apps that have been backed up in the Google Drive.
But still I would like to clear things from so because it makes easy to understand than a document.
Here are few points I messed up.
Restore schedule
The device can restore from either its own backups or the ancestral
dataset. The device prioritize its own backup if backups from both
sources are available. If the user didn't go through the device setup
wizard, then the device can restore only from its own backups.
This can go upto 25MB.Let's say I uninstall an app an reinstall it again.Not at what stage it takes the backup? Do i need to follow any technique eg: like a splash till it completes onRestoreFinished()? if there is like 20 MB data? Any good example for this?
Enabling and disabling backup
<application ...
android:allowBackup="true">
</app>
To disable Auto Backup, set android:allowBackup to false. You may want
to disable backups when your app can recreate its state through some
other mechanism or when your app deals with sensitive information that
should not be backed up
This line is in the Manifest so what can be the best way to make it false once the backup task is done.Let's say registration is done and that's all i want to back up.How can I update that tag value at run time?
Is there any way to reset 25MB backup quota by deleting the existing backup?
Thanks
Not at what stage it takes the backup? Do i need to follow any technique eg: like a splash till it completes onRestoreFinished()? if there is like 20 MB data? Any good example for this?
Lucky for us developers, this is done automatically, during the app installation, which can occur in a few situations:
Data is restored whenever the app is installed, either from the Play store, during device setup (when the system installs previously installed apps), or from running adb install. The restore operation occurs after the APK is installed, but before the app is available to be launched by the user.
From restore schedule
This line is in the Manifest so what can be the best way to make it false once the backup task is done.Let's say registration is done and that's all i want to back up.How can I update that tag value at run time?
That is not possible. As you can read in Backup schedule, it is automatically done on a somewhat regular interval. If you have requirements that conflict with this schedule, you have to implement your own backup mechanism.
Is there any way to reset 25MB backup quota by deleting the existing backup?
This is not necessary. Only one backup exists at a time. When a new backup is made, the old one is deleted:
Backup data is stored in a private folder in the user's Google Drive account, limited to 25MB per app. The saved data does not count towards the user's personal Google Drive quota. Only the most recent backup is stored. When a backup is made, the previous backup (if one exists) is deleted.
From backup location
Related
I have an app that creates a directory for backup files on the external storage and automatically creates backup files when the user exits the app. One backup file per week is created and then one backup file that is overwritten all the time with latest info.
The backup files can't be located in getExternalFilesDir since they needs to survive that the user reinstalls the app.
I can't use MediaStorage because it's not an image or video.
I can't use Storage Access Framework to ask the user every time he exits the app to save a backup file.
So how to automatically create persistent backup files with the new Scoped Storage?
(I also need to list all created backup files, if the user wants to restore one of them.)
Backup is appropriate in the case when the user loses the device, buy new, install the app, login and get his data as they were.
Your question is looks like you try to leave on the user device something that he probably doesn't need, as far he deletes the app. If it's the general files like images, music, documents that many apps can view or edit - leave them there and do not care. If it's only your app data - they should live while your app is installed and die when the app is deleting.
It makes sense to back up to the cloud only. In case you don't need a personal server, here is the option: implement syncing with Dropbox or Google Drive. It's the best option just to update the app's data after each closing of the app using the service.
My question is concerning the Android app data backup feature configured by android:allowBackup in the manifest, as documented here. As I understand it, this backed-up app data is restored when the user uninstalls and later re-installs an app from the play store.
In this scenario, when exactly is the data restoration done? Is it:
During installation from Play Store, before user has ability to open app
After installation is complete, potentially allowing user to open app before the restore is done
Our users are on slow internet connections and a few have reported scenarios where data they entered shortly after a reinstall is replaced by old data from past backups. If the Google backups are to blame, this seems to suggest that the restore is done after install (#2 above), but I can't find concrete information to back this.
I'm slightly skeptical because this backup feature is enabled by default. If this overwriting can indeed happen on reinstalls, this would mean all android apps under android 6+ will have encountered issues where first-time setup data (auth tokens and such) is overwritten when a restore is applied. Does anyone have any links or anecdotal information on whether this theory is correct?
Auto backup in android
Check "Restore schedule" para which says that restore happens after the APK is installed, but before the app is available to be launched by the user. BTW if you want to handle Autobackup, you can follow the setup step on codelab Autobackup setup for Android Codelab
How to check if the app is a fresh installation or a re installation. I want the user to have his history downloaded if its a re-installation like whats app. I thought of writing the user id in the shared preference but that is not possible as the data may get erased once the app is uninstalled. I am already having a folder of my app on the device which is used for image caching and downloading new images, but this is not reliable as the user may delete the folder. What else can I try ???
Obtain the user storage with getExternStorage, then leave a file there that specifies the usage history. The file you save there will survive uninstalls and reinstalls. Of course the user can delete that file but generally they will not, and if you name it properly they will realize it is part of a program.
I'd suggest you integrate with Android's Backup Service.
People switch phone every two years. Some factory reset their device. Some have more than one device. And some share their device with their kids. Linking a user history so that it follows a particular google account is the ideal way to go.
As to your question regarding Facebook integration, I'm afraid I know too little about that topic to be of any help.
I want to save some info regarding a trial version an application.
I want this info to be persistent in order to detect if the user removed the application and installed it again after the trial expiry.
what is the best place to store such info
thanks
Most of the times the solution to this problem is to keep an server side check,
But if you dont want to involve a server its better to give some limited functionality in your trail app and full in the paid version.
There are other methods too like Time Trial but again they all depends on persistent data so they also fails if the user uninstalls and installs again your applucation
Store it in external file.
it wont be deleted after user uninstalled the app.
but
Serverside check by Device ID is the good way ..
I'm working on the same "problem" at the moment (offline solution for trial time expired apps):
My findings: There is no way to ensure that a user never can reinstall & reuse a (time) trial app but there is a way to 'nearly' prevent it:
Use shared preferences / a database / file saved on internal storage containing the install timestamp.
If the device has an external storage card (most devices have) also save the timestamp on the sd card.
The only possiblity to use your application also after expiring is if the user 1. clears app data on the phone and 2. finds the timestamp file on the sd card and also kills this one.
If he "just kills" the first or second check the killed one can be restored on next app start.
When I update some applications, I see some show "Manual update". I believe this will force uninstall of old version first and the installs fresh.
1. Is it true?
2. How do I FORCE uninstall of new version (with all preferences etc.), and install the new version fresh?
The manual update isn't going to uninstall your application, then reinstall, what is happening is because the dev has changed a security requirement of the app, the user needs to agree to it again.
So for example, if I developed a word search app with no security requirements, the user agrees to install it and uses it so decides to tick the auto update, or hits update all. My first update is simply adding puzzles - it would update fine.
I now add a feature to read a users SMS and their Contacts and use the internet to send me all the details.
The security privileges of my app have changed - now my app will not be included in the auto update or update all as the user needs to agree to these new security privileges and thus hopefully alerting the user to the outrages nature of the security requirements for this type of app.
Read More Here
If what you are trying to achieve is wiping all users data, then you need to add this to your code as I don't think it is possible to do this as a market update option (I could be wrong as its not something I would normally recommend).
To do it in code, a simple look at the app version code, and if its below X then delete prefs & or DB would do the trick I would have thought.