I have preserve data/cache checked in the settings but whenever I do a debug build onto my android device it always uninstalls the old apk and reinstalls the new one.
The Preserve data/cache option has nothing to do with whether the .apk is uninstalled or not.
The Preserve data/cache option controls whether the .apk is uninstalled with `adb uninstall -k` or not:
> ('-k' means keep the data and cache directories)
The .apk contains all Android resources, assets, and Java code. If any of these changes for any reason -- e.g. resources are added or changed, or a C# class was altered to override a new Java method -- then the .apk MUST be rebuilt and redeployed. There is no way to avoid it.
so there's no way to change it to just install with -r? It seems like my data is getting wiped every time I deploy a build.
also this would be better because when you force an uninstall/install any widgets/home screen shortcuts that had been set are removed. If you guys need proof that my data is getting removed when i push builds I can send a video or something.
Ran some manual tests and found that "preserve data/cache between application deploys" was working as expected.
Used monodroid-samples/Notepad on Debug mode and followed the steps below:
install app that preserves data/cache
go to "preferences > projects > android > tun on preserve data/cache…"
clean and rebuild app
deploy app and store some data
go to "preferences > projects > android > turn on preserve data/cache…”
clean and rebuild
redeploy app with preserve data/cache on via XS
observe that data should be preserved
go to "preferences > projects > android > tun off preserve data/cache…”
clean and rebuild
redeploy app with preserve data/cache off via XS
observe that data is gone
Link to sample:
Try this on the google n6 with latest lollipop - it seems to only happen on this device.
Followed the same steps as listed in Comment 4 with a Nexus 6 (5.0.1) and could not reproduce the issue. Everything worked as expected.
I will try with the notepad sample app and get back to you.
I reproduced the bug.
1. Install notepad app -> make a note.
2. make some changes to the xml in the notepad app (I added <Button android:layout_width="4dp"
3. push the app with xamarin
4. The note you previously created will be gone (on nexus 6 lollipop).
if you then push builds without making changes it does preserve data. but if you make changes it doesn't.
Also ensure that xamarin says "removing previous version of the application" when you are pushing - as I believe this is where the data gets removed.
Followed the steps in Comment 8 with a Nexus 6 (5.0.1) and was unable to reproduce the bug with preserve data/cache checked. Also ensured that it was "removing previous version of the application" as per the suggestion in Comment 9.
Could you please give details on your Xamarin Studio setup? Go to the tab option "About Xamarin Studio > Show Details" and then provide the information. It will look like this:
Hmm maybe it's just something wrong with the phone.. like because it's rooted or something. Let me try adb uninstall/reinstall with -k and see if that works. here is my xamarin setup.
> so there's no way to change it to just install with -r?
Long delay, I realize... At the time, I tried to figure out why we didn't use `adb install -r`, and couldn't find an answer.
Now, I might: `adb install -r` is unreliable, at least for me:
If `adb install -r PACKAGE` doesn't actually make the updated package usable on the device, it's *broken*, and that's what I and a co-worker had to debug through for *hours* last week...
Different app, different device, app data is always wiped, including SharedPreferences and GoogleApiClient data. Need to login every time.
Please fix it. We two are not the only one complaining about it.
Have exactly the same problem:
- "Preserve application data" - CHECKED
- Using Android Authenticator component (extends AbstractAccountAuthenticator).
- Need to re-login to the app after EVERY deploy to the device.
I understand that the issue 'adb install -r' is unreliable on some cases. But at least give it as an option...
I believe it's the same as issue described in Bug 32443