I'm using the default backup manager ,BackupAgentHelper for shared prefrences
can someone explain these errors:
1.W/PackageManager: checkUidPermission(): android.permission.BACKUP of 10129 is denied.
2.W/RestoreSession: No data available for this package; not restoring
what are the possible cases in which backup does not occur.
note:I have already added android:allowBackup="true" attribute.
note2: i know the backup process doesn't create instant backup. i have tried waiting for 1 day.
I saw many people facing problems in using the Key/value backup API provided by Google. In my case, due to following reasons my backup/restore functionality was not working.
when you request backup using BackupManager.dataChanged() it doesn't backup your data instantly. I waited for 1 day,but my phone wasn't connected to Internet for long.so my backup was scheduled but never occurred.
while restoring data do remember that even after restore is finished, your shared preferences are not refreshed i.e sharedPref.contains("mypref") will return false.I don't know if its a bug or not, but when the activity is killed and restarted again shared preferences are set.
for Testing purpose you can view this link to have instant backups and restores
This backup API does not require any special permission. just
<application
android:allowBackup="true"
android:backupAgent="CreateBackup"/> is enough.
Related
I am using the Android AutoBackup feature in my app. These are my manifest settings.
<application
android:allowBackup="true"
android:fullBackupContent="#xml/backup_rules"
android:fullBackupOnly="true"
Is there a way to know when the last backup for my app was made?
The only thing I have found says this:
schedule
Backup documentation
Frequency Apps must issue a request when there is data that is ready to be backed up. Requests from multiple apps are batched and executed every few hours. Backups happen automatically roughly once a day.
Also, it looks like if you write your own agent you can register for backup or restore events.
events
also, one last thing, when you implement the events it looks like backup gives access to the date of the last backup. As far as I can see, a customs agent gets you the info you need with some coding
examples
Users reported to us that they uninstalled the app, then reinstalled it and they were immediately transferred to the Home screen, instead of the Login screen. The thing is, since they don't login they don't have a Session token and hence, they can't call cloud functions!
Here's my check:
if (ParseUser.getCurrentUser()==null) {
// show login screen
}
else {
// show home screen
}
Here's an email we just got
I have managed to fix the problem. I had to clear all my temporary data for the application and reinstall it. After that it worked like it should. So the problem was with some temporary saved data in my device.
Any idea what's going on?
In AndroidManifest under the application tag, there is an android:allowBackup
flag that was responsible for this. as the documentation said:
android:allowBackup Whether to allow the application to participate in
the backup and restore infrastructure. If this attribute is set to
false, no backup or restore of the application will ever be performed,
even by a full-system backup that would otherwise cause all
application data to be saved via adb. The default value of this
attribute is true.
For your problem, you must make this false.
The Android docs say:
By default, Auto Backup includes files in most of the directories that
are assigned to your app by the system
Shared preferences files
Files saved to your app's internal storage
etc
However, my app currently stores a SharedPreference item that isn't being saved after uninstalling.
Before I uninstall my app, my shared preference sharedPref.getInt("locationCount", 0) is 2. But when I uninstall and reinstall, it's reset back to it's original value of 0.
AndroidManifest.xml
<application
android:name=".CustomApplication"
android:allowBackup="true"
android:supportsRtl="true"
android:usesCleartextTraffic="true"
Any idea why it isn't saving?
Backups occur automatically when all of the following conditions are met:
The user has enabled backup on the device. In Android 9, this setting is in Settings > System > Backup.
At least 24 hours have elapsed since the last backup.
The device is idle.
The device is connected to a Wi-Fi network (if the device user hasn't opted in to mobile-data backups).
I noticed that re-installing my application (building it again and again in debug mode) sometimes clears my SP and sometimes not.
I thought that adding android:allowBackup="true" in the application tab in the Manifest.xml file might restore it anytime I re-build the app.
<application
android:allowBackup="true"
.
.
.
>
Does building the app over and over actually uninstall it and then re-install it? And if it actually works like that, does it work the same for release mode?
What android:allowBackup="true" actually does? I thought it creates a permanent file on the phone pointing to the important data that needs to be backed-up.
When updating an app via Google Play, what is the actual process? Is the app uninstalled and then re-installed? Or does it just update the necessary code?How does it affect the memory?
What is the real reason of my Shared-Preferences actually getting deleted?
When it comes to things like shared preferences, they typically should be preserved between debugging sessions (assuming you are not manually deleting the app from the emulator/device).
Check Visual Studio's setting to ensure that it is trying to preserve data/cache directories:
Preserve data/cache between application deploys
Read the section on "Fast Deployment" for how Xamarin handles debug build updates:
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-process
During development "Auto Backup" (android:allowBackup="true") is pretty much irrelevant, see the conditions below in which is it back up to your Google Drive account.
Backups occur automatically when all of the following conditions are met:
The user has enabled backup on the device.
At least 24 hours have elapsed since the last backup.
The device is idle.
The device is connected to a Wi-Fi network (if the device user hasn't opted in to mobile-data backups).
The Android (Back up user data with Auto Backup) documentation cover this in more detail.
I'm new in Android. I have an Idea to enrich user's knowledge whilst installing a desired application.
the idea is developing an application that can analyze .apk file of the application to check if it's over-privileged or not. and inform the user if this application which he's trying to install is over-privileged or not.
but since there's already a mechanism from Android which asks user's consent to grant whatever permission the application requests, I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it or it can not.
I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it
None of these are possible, sorry. You are welcome to create your own custom firmware that has this feature, but you cannot create this capability via an SDK application, for obvious security reasons.
I am not far from where you are ~ the entire mechanization you seek is based on an xml file in the "root" of the installation - it is called AndroidManifest.xml = all permission based issues should begin original first efforts on that file:
The AndroidManifest.xml File
Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. Among other things, the manifest does the following: .....
the "app-store" web based distribution system is supposed to pick that up and not only make some decisions on what to present to the user but as well differentiate to some extent what to do in the matter but as I just got a Droid-X emulator available in my installation I can tell you for a fact that "versioning" is subject to oversimplification as we cannot rely on users being tech-geeks