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.
Related
I am doing a targetVersion upgrade in my app. Now I have a problem. When I go to phone settings, I manually refused permission. When I go back to my APP, I want to restart it and return to MainActivity. Now when I go back, it just restarts the current Activity. Can you give me some advice?
I checked some programs. They confirmed whether they were modified by judging savedInstanceState != null. I think this is wrong because I backed up the data in savedInstanceState and only judged savedInstanceState != null is not OK, it is one-sided.
You'll need to store your data in more persistent matter (shared preferences, database, files, whatever applies) and manually restore it.
When user revokes permissions through settings app process gets killed without any callbacks to prevent unwanted behavior, for example:
Activity checks READ permission in onCreate
user pauses activity and revokes permission in settings
Activity resumes assuming it still owns permission and crashes on read attempt
This includes killing all ongoing services as well. Regular Activity lifecycle doesn't apply in that case.
Either you can check in OnResume if the permissions have changed. However this would hten be done whenver you just "tab out and tab back in*" to the application. A better way would be to check if savedInstanseState !=null and if so you recheck the relevant permissions, and if they have changed you finish() the activity to go back to MainActivity, and/or send an intent to restart the MainActivity if that is needed.
savedInstanceState can be "not null" in more cases than changing the permission as you pointed out, so you should recheck the relevat permissions to make sure that something actually changed.
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 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.
I am writing an app which uses the SyncAdapter framework. By default, the user has to activate the sync in the android account settings.
However, I was told that by calling
ContentResolver.setIsSyncable (mAccount, AUTHORITY,1);
I can activate the syncing without any user interaction.
Sadly, this doesn't seem to work. Even after a complete reinstall of the app, the sync adapter service is not running and the account settings look like this:(See screenshot below.)
What could I possibly be missing? Is it a problem maybe that I am calling ContentResolver.setIsSyncable (mAccount, AUTHORITY,1); from the content provider as opposed to the activity?
I would like to require that a user type a password before being allowed to uninstall/remove my application. How can I implement this functionality?
You could do this by:
The first time your app is installed, install a separate application/package ("watcher").
The only classes "watcher" contains is a BroadcastReceiver that listens for ACTION_PACKAGE_REMOVED
Add a BroadcastReceiver to your application that also listens for ACTION_PACKAGE_REMOVED
When a intent is broadcast to one of your receivers, check if the other component is still installed. If is isn't (the user just uninstalled it), prompt for the password - if it's wrong, reinstall the other component. If it's right, uninstall yourself.
You can exec logcat and get the start activity intent information.
You will find that before the uninstall activity is displayed, there is
a text msg such as:
Starting activity: Intent { act=android.intent.action.DELETE dat=package:com.comodo.pimsecure cmp=com.android.packageinstaller/.UninstallerActivity }
then you can pop a activity ask for password now.
It is possible. you can do it with DeviceAdminReceiver api. (i don't no how)
This is a hard problem. I can think of at least one non-evil use-case for it.
e.g. Stolen Phone Recovery app - you wish to deter ne'er-do-wells from uninstalling the app.
In this case, I can think of two sensible assumptions which would stop me implementing what you're looking for:
the thief is unaware of your app, so will not try to uninstall it.
the thief is aware of your app, and switch it off until he can get it to an iron box* to re-install the OS.
* For the uninitiated: an iron box will prevent the device sending or receiving electromagnetic signals.
Of course, this answer amounts to You Ain't Going To Need It, though I suspect you have already thought this through.
Protect installing/uninstalling apps by password makes Android more secure from malware/viruses. Your Android become as secure as iPhone.
How it works:
Automatic apps installing is prompted to user. You can search the app name. If not secure, Block it.
Root access is prompted to user. Too many ads is an indicator that access is dangerous.