0

Background: As part of an upgrade to A6/MM, I ended up having to wipe my phone. I did however back up /data/app and /data/data before I wiped. After the upgrade I rsync'ed /data/data back to the phone. Then I proceeded to re-install some apps from google play.

I expected the app data in /data/data to be used, but instead the app install first failed, but on 2nd attempt the install worked (finished), BUT it overwrote all my settings (etc) that I had restored into /data/data. My question is, how do I avoid this? Was the first install fail because the app installer saw the old data?

The app in question was Zoiper Lite, but I don't think the specific app is terribly significant. Is there something about wiping (factory reset) that causes the apk install process to expect no data and therefore fail, but then erasing data if you insist with a 2nd attempt? Of course, what I really want is a workaround so I can install the app AND keep the old data. I have lots of apps for which I would like to do this, so it is definitely a problem...

  • 1
    Why not install the app and then rsync its data? That said, some apps generate install-specific data in there (such as API access tokens), so it can't necessarily be reused from one install to another. – Dan Hulme Mar 8 '17 at 11:24
1

DO NOT create the folders before the app itself does, as you often won't be able to get permissions, ownership and contexts right. Instead, after a new install, run the app once to let it create the file structure, then proceed to overwrite. It's also highly recommended to find which exact file(s) stores the preferences/data you want to restore - usually just some XML files in shared_prefs sub-folder - and restore them only.

The final solution to such problems in the future would be just using apps like Titanium Backup to automate the backup/restore process.

EDIT: I downloaded Zoiper myself and tested: I modified some preferences, backed up /data/data/com.zoiper.android.app/shared_prefs/com.zoiper.android.app_preferences.xml, then cleared data and re-ran the app to let it generate structure. I restored the pref file afterwards, and they did get restored after I did the 1st trick. The thing is, don't forget to first force close the app before you try to replace stuff, or the running app will simply ignore it.

  • When replacing files, take very good care of ownership. Each app gets a Unix user/group assigned on install – and with a fresh install, it's rarely the same it was before. So full ack on "TiBu does the job" :) – Izzy Mar 8 '17 at 8:06
  • @Izzy Damn, ownership! I knew I missed something but couldn't grasp it when writing... Edited – Andy Yan Mar 8 '17 at 8:13
  • @Izzy Weirdly, in my experience, although putting a full structure without taking of ownership, etc. won't work, overwriting a single file does, and after opening the app next time, the permission and ownership are corrected to their intended values... Android sure works in ways I can't comprehend right now. – Andy Yan Mar 8 '17 at 8:15
  • 1
    Nothing unusual, Andy. If the app owns the directory, it can delete/replace all files within. If it doesn't own the directory, it cannot do a thing with the contents. So if you replaced the entire structure, the top-level directory (and all within) belonged to "another user", and the app couldn't deal with it – while when you placed a single file, it could. Same thing on Linux/Unix; I remember it back from my days at the university, where we shared folders in our students' group: who owned the folder had the power :) – Izzy Mar 8 '17 at 8:47
  • @Izzy Wow. So it's *nix working in ways I need to learn badly. Now I gradually know why seniors said to me "you're never too old to learn Linux"... – Andy Yan Mar 8 '17 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.